🚀 go-pugleaf

Magnus.Hjern@malmo.trab.se (Magnus Hjern) writes:

>We are using CAP patch 126 running on a DS5120 with Ultrix 4.3. The
>aufs fileserver for Macintosh workstations has been running for about
>8 months now, without any major problems. The only thing we've noticed
>so far is that the desktop files are not handled correctly by CAP.

>If the user would like another layout on his/hers CAP-folders than the
>standard ones, the changes are not stored by aufs. Even if the
>ADeskTop and .IDeskTop files are deleted and rebuilt it does not have
>any effect on the layour. 

 We've experienced this, also. The problem only exists in the "root"
 directory of that shared volume. All of the subdirectories will store
 the files' locations just fine. We have not figured out how to solve
 this problem and have basically concluded that it's just a bug.

--
Chris Trimble	                | Birthday party, 
B.I. Systems Services           | cheesecake, jellybeans,
chris1@uiuc.edu                 | BOOM!					- R.E.M 

>  We've experienced this, also. The problem only exists in the "root"
>  directory of that shared volume. All of the subdirectories will
>  store the files' locations just fine. We have not figured out how
>  to solve this problem and have basically concluded that it's just a
>  bug.

Actually, you are probably experiencing something which is in the
spec.  When I asked about this quite a while ago David Hornsby noted:

> The AFP spec contains this little peculularity in that to make the finder
> info stick, you have to be the owner of the volume in question (so that
> the owner bit is set in the permissions block, Ref: Inside AppleTalk 2,
> page 13-88, lower right).
> 
> So, my guess is that if you mount the volume as the user who owns the
> directory, then things should work OK. In addition, CAP 6.0 has the ability
> to set this stupid bit by having the directory setuid bit set, ie:
> 
> 	chmod u+s volname
> 
> so others can save the finderinfo on a shared volume.
> 

This helped my problem, I hope it solves yours (and the original
poster's).
       Peace,
          dNb
--

 David N. Blank-Edelman              o/    \  /    \ /     /      \o   
 M.I.T. Media Laboratory            /#      ##o     #     o##      #\
 E15-473F, (617) 253-2169           / \    /  \    /o\    / |\    / \

In article <trimble.726431386@ph-meter.beckman.uiuc.edu>, trimble@ph-meter.beckman.uiuc.edu (Chris Trimble) writes:
> 
> Magnus.Hjern@malmo.trab.se (Magnus Hjern) writes:
> 
> >If the user would like another layout on his/hers CAP-folders than the
> >standard ones, the changes are not stored by aufs. Even if the
> >ADeskTop and .IDeskTop files are deleted and rebuilt it does not have
> >any effect on the layour. 
> 
>  We've experienced this, also. The problem only exists in the "root"
>  directory of that shared volume. All of the subdirectories will store
>  the files' locations just fine. We have not figured out how to solve
>  this problem and have basically concluded that it's just a bug.
> 
> --
> Chris Trimble	                | Birthday party, 
> 
I had similar problem with the "root" directory. I solved it by making
finderinfo and .resource directories also into parent directory of
aufs "root" directory.

My directory hierarchy looks like following:
<my Unix home directory>
  .
  ..
  .finderinfo
  .resource
  .afpvols
  <other .files>
  mac_files
    .ADeskTop
    .IDeskTop
    .finderinfo
      <Finder info of Mac files>
    .resource
      <resource forks of Mac files>
    <Mac files>
  <other Unix files and directories>
=========================================================================
Ari Ahonen         TELECOM FINLAND/Business Systems R&D            X.400:
                   Phone: +358 0 704 2940  C=FI; ADMD=MAILNET; PRMD=INET;
                   Fax:   +358 0 704 2712  O=TELE; OU1=AJK; OU2=QM;
Internet: Ari.Ahonen
=========================================================================

>If the user would like another layout on his/hers CAP-folders than the
>standard ones, the changes are not stored by aufs. Even if the
>ADeskTop and .IDeskTop files are deleted and rebuilt it does not have
>any effect on the layour. 
>
>Does anyone have the solution to this problem?

This ought to be in the FAQ list, if it isn't already.

The folder layout information is not stored in the .ADesktop/.IDesktop
files - these hold icon information and application-location bindings,
but not visual-display info.  Instead, it is stored in the .finderinfo
directory.

Your problem is probably this:  the Finder layout information for the
top-level directory (the "disk window" layout) is being lost, because
CAP cannot find a place to store it.  The information is _not_ stored in
the directory that you are "publishing" on the network - instead, it's
stored in the .finderinfo directory which is located "in parallel" to
this top-level directory.  You probably have not created this
.finderinfo directory or have not set the permissions properly.

By way of example:  if you wish to publish /foo/bar/baz as a Macintosh
network disk, you must create _four_ Unix directories:

	/foo/bar/baz
	/foo/bar/baz/.resource
	/foo/bar/baz/.finderinfo
	/foo/bar/.finderinfo

The last of these is probably the one that you are missing.  You should
create it, and set its ownership and write-permissions to be identical
to those of the other three.  Then, dismount the network volume, mount
it again via the Chooser, and set the "View by" arrangement to whatever
you wish - this time it will "stick" properly.
-- 
Dave Platt                                                VOICE: (415) 813-8917
              Domain: dplatt@ntg.com      UUCP: ...netcomsv!ntg!dplatt
 USNAIL: New Technologies Group Inc. 2470 Embarcardero Way, Palo Alto CA 94303

Given that there were a few informative replies to the problem of getting
the root directory of an aufs volume to display as a user wanted I thought
I'd have another try at getting help me with this.

Basically, if I double click on a document for which the application is on
an aufs volume the application will not be found unless the folder which it
is in is currently open.

I setup a server volume, copied Resedit onto it then deleted it from my
disk. I double clicked on a Resedit document and was told that the
application could not be found. I opened it the folder (the server volume)
it was in, double clicked on the document and the application was found.
When I closed the folder again it wasn't found... It behaves the same way
for things in the top level of a server or for things in folders in a
server.

My machine is a Q700 running 7.01 but it happens on anything. The server is
a DecStation 500/200 running Ultrix 4.1 and CAP 6.0pl125.

Here is the directory structure of the server called test_mac.

drwxr-xr-x  2 bruce-b       512 Jan 12 14:57 .finderinfo
drwxr-xr-x  4 bruce-b       512 Jan 12 14:59 test

test:
total 10
drwxr-xr-x  4 bruce-b       512 Jan 12 14:59 .
drwxr-xr-x  8 bruce-b       512 Jan 12 14:55 ..
-rw-r--r--  1 bruce-b       251 Jan 12 14:57 .ADeskTop
-rw-rw-r--  1 bruce-b      4880 Jan 12 14:49 .IDeskTop
drwxr-xr-x  2 bruce-b       512 Jan 12 15:00 .finderinfo
drwxr-xr-x  2 bruce-b       512 Jan 12 14:57 .resource
-rwxr-xr-x  1 bruce-b         0 Jan 12 14:48 ResEdit

test/.finderinfo:
total 3
drwxr-xr-x  2 bruce-b       512 Jan 12 15:00 .
drwxr-xr-x  4 bruce-b       512 Jan 12 14:59 ..
-rwxr-xr-x  1 bruce-b       300 Jan 12 14:51 ResEdit

test/.resource:
total 738
drwxr-xr-x  2 bruce-b       512 Jan 12 14:57 .
drwxr-xr-x  4 bruce-b       512 Jan 12 14:59 ..
-rwxr-xr-x  1 bruce-b    743448 Jan 12 15:04 ResEdit

Any help would be greatly appreciated.

---
Bruce Benson.   	       	       	       	       ,_o ,__o
Department of Computer Science. 	       	     _-\_\,\_<,
University of Auckland. 	       	       	    (*)/'--/'(*)
b_benson@cs.aukuni.ac.nz

I am having a similar problem with respect to view information not
being kept.  If this is a FAQ, please point me in the right direction.

I'm not the sysadmin but I'm allowed to write to a publically
available volume.  (CAP AUFS was installed by the previous sysadmin
and the current one knows little about it.  I'm hoping to find out
here the answer to my problem so that I can pass it on to the new
sysadmin.  It's easier to get things fixed if you can tell someone how
to do it...)

In order for several people to be able to write to the PublicVolume, a
unix group (say apple) was created.  All the files in the PublicVolume
(in the unix world) are given rwX permissions for the owner and group.
All people that should be able to write to PublicVolume are included
in the apple group (including me).  Is this a reasonable idea in the
first place?

I can now write files and folders to the PublicVolume, including into
folders that I don't own.  If I set the view for these folders (those
owned by someone else) to "by Small Icon" or "by Icon", things look
fine until I reopen the folder.  (Other views seem to work fine.)
Subfolders of which I'm owner all appear on top of each other in the
upper-left corner of the folder.  (This behavior seems worse when
viewing "by Icon".)  I believe I've made sure that all necessary files
exist and have the correct permissions.

For example, assume that the file
   .../Mac/PublicVolume
is mounted as a public volume and that the unix world looks something
like (I haven't included all the files):

   File:                                   Owner:    Group: Perms:

   .../Mac/.finderinfo                     ftpadmin  apple  drwxrwxr-x
           PublicVolume/                   ftpadmin  apple  drwxrwxr-x
                        .finderinfo        ftpadmin  apple  drwxrwxr-x
                        .resource          ftpadmin  apple  drwxrwxr-x
		        foo/               ftpadmin  apple  drwxrwxr-x
                            .finderinfo    ftpadmin  apple  drwxrwxr-x
                            .resource      ftpadmin  apple  drwxrwxr-x
                            Original       ftpadmin  apple  drwxr-xr-x
                            Mine           maariano  apple  drwxrwxr-x
                                /*         maariano  apple  

Changing the view of foo works once at most.  After that, the folder
Mine (and any other similar folders) appears on top of the folder
Original.  The foo/.finderinfo file is even modified.  Views within
Mine are 'remembered'.

Is this a bug or just a feature due to trying to to use CAP AUFS
inappropriately?  Any help would be appreciated.
--
Marco Ariano                      Alberta Research Council                
maariano@skyler.arc.ab.ca	  Advanced Computing and Engineering Dept.
ph:  (403) 297-2672		  Calgary, Alberta                        
fax: (403) 297-2339		  Canada  T2E 7H7