Subject: [netatalk-admins] Re: Yet Another Netatalk problem (YANP)

From: Jay <[email-masked]>
Date: Wed, 20 Aug 97 12:05:50 -0700

I'm learning a little more about the problem I'm having copying files 
with netatalk1.4b2+asun2.0a14 and Mac OS 8.  I've included my earlier 
email on this topic, and a reply, below.

The problem is not with the Resource Fork per se, but with the Finder 
Info.  Mac OS 8 is happy enough to work with files that don't have a 
Resource Fork.  Of course, both are stored in the .AppleDouble directory 
on a netatalk volume.

Mac OS 7.6.1 has no problems with netatalk1.4b2+asun2.0a14 and read-only 
directories, so it would appear that Mac OS 8 is doing things differently.

Mac OS 8 has problems (e.g., will not sucessfully copy) not only files in 
read-only directories, but any file that hasn't previously been "seen" by 
a Mac OS client.  For some reason, a Finder copy will not cause the 
Finder Info to be created by netatalk, but opening the folder will.

Question:  Why does netatalk insist on creating the Finder Info for Unix 
files (e.g., files that were created on the server, not by a Mac OS 
client)?  I could see this as a caching mechanism to avoid having to 
synthesize the Finder Info each time, but netatalk should not _require_ 
the presence of the Finder Info in the .AppleDouble directory to function 
properly.

Here's hoping you netatlk source jocks are able to come up with something 
to fix this.  Netatalk and Mac OS 8 are still not happy campers.

Jay O'Conor
[email-masked]

 >-----<snip>-----
>>I think this one might have been mentioned on this list before, but I
>>can't seem to find it in the archives...
>>
>>I'm having another "file not found" problem when copying files from a
>>netatalk volume.  This time, it is with files that are in a read-only
>>directory, and therefore there is not a .AppleDouble directory within it.
>>Here's a test that reproduces the problem:
>>
>>1) From the netatalk server, create a directory named "foo" (mkdir foo).
>>Do this in a directory this is visible via netatalk.
>>2) Create a file in the foo directory (optional) (touch foo/bar).
>>3) Change foo so it is read-only (chmod a-w foo)
>>4) On the Mac client, cause the parent folder of foo to be re-read
>>(remount the volume, or close and reopen the parent folder, whatever)
>>5) Try to copy the now visible foo folder to a local Mac disk.  Bzzzzzt.
>>Won't work.
>>
>>I'm running Mac OS 8 with netatalk 1.4b2+asun2.0a14.  I didn't have this
>>problem with netatalk 1.4b2 (no patches) and Mac OS 7.6.1.
>>
>>Anyone familiar with this one?
>>
>>
>>Jay O'Conor
>>[email-masked]
>
>-----<snip>-----
>
>Under OS8 I see the same problem. It seems that OS8 is not happy with the
>absence of a resource fork, even just on data files. It also wont let some
>applications open those files without an error.
>
>In order to be able to copy the files you must have them in a directory
>that is writable by the client and then open the folder window, this
>creates the appropriate entries in .AppleDouble and then you can drag them
>elseware on the Mac. There may be other work arounds that would allow you
>to keep files in a locked folder, but I haven't pursued them.
>
>The only problems I've had with OS8 have been with appletalk. My finder
>gets hosed up whenever I do something unusual, sometimes quitting
>unexpectedly and restarting, not always sucessfully.
>
>-James
>__________________________________________________________________
> James Sentman                            [email-masked]
> Internet Systems Specialist                            Media One
>
> http://www.mediaone.com/          http://shoga.wwa.com/~sentman/
>__________________________________________________________________

---

From: a sun <[email-masked]>
Date: Thu, 21 Aug 1997 06:48:51 -0700 (PDT)

netatalk doesn't and really shouldn't have any idea of what the finder
info should be. it's only supposed to save it and not fiddle with
it. for read-write volumes, this works out okay. when asked about a
file w/out a corresponding .AppleDouble entry, netatalk sends a bogus
finder info entry and the mac client comes back w/ a fixup reply. 

on read-only volumes, this is going to be difficult to solve for the
general case as the fixup gets rejected. however, i should be able to
peek in the os8 technote and modify the default finder info reply so
that it works. ugh. 

-a

---

From: William Uther <[email-masked]>
Date: Thu, 21 Aug 1997 10:28:48 -0400

a sun wrote:
>when asked about a

What does the current os8 AppleShare client do with a normal server that is
both locked and hasn't been used with os8 before?  I assume it would have
the same, incorrect, finder info as netatalk.  If the volume is not mounted
for writing you shouldn't be able to change the finder info there either -
or is this a security hole in old apple servers?

\x/ill         :-}

William Uther            "When I die I want to go quietly,
[email-masked]            in my sleep like my Grandfather,
Dept. of Computer Science,   not screaming like the passengers in his car"
Carnegie Mellon University         http://www.cs.cmu.edu/~will/