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

From: Jay <[email-masked]>
Date: Thu, 21 Aug 97 15:34:00 -0700

>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. 

Interesting approach.  I would have thought that it would send legitimate 
finder info since I'm assuming that netatalk has to synthesize something 
halfway reasonable for files mapped by AppleVolumes files.
The current approach also cause problems for Mac OS 8 when a copy is 
performed on a file that has no entry in the .AppleDouble directory.  
Finder copies don't seem to trigger the creation of finder info in 
.AppleDouble.  If the entry doesn't already exist, the copy fails with 
the usual "file couldn't be found" message.

---

From: a sun <[email-masked]>
Date: Thu, 21 Aug 1997 15:49:01 -0700 (PDT)

well, it send 0's in the hope that that works. anyways, i've put up a
pre-a15-2.tar.gz at ftp.u.washington.edu:/public/asun which actually
fills in the finder info a bit. i would like people to test it on both
os8 and os7 machines to see if it does the right thing. 

the test:
	create a dummy file: dummy.doc
	mount the appleshare volume
	  you should see dummy.doc w/ the correct icon for its type.
	  you shouldn't see finder jumpiness.
	peek in the corresponding .AppleDouble directory. you
	  shouldn't see dummy.doc.

also, for those having difficulties copying files to their netatalk
server (bsd machines, from the sound of it), could you run w/ -d and
report to me both the command and reply codes? something like the
following should work:
	grep -e "commands:" -e "reply" logfile

syslog's are also useful. the only test case i've been able to look at
reports an impossible error code. truly confusing.

-a