Subject: [netatalk-admins] minor addendum

From: a sun <[email-masked]>
Date: Fri, 25 Sep 1998 18:06:00 -0700 (PDT)

hello all,

for those that were trying pre-10, please get pre-asun2.1.0-10a.tar.gz
instead. i noticed that at least my machine doesn't like to realloc a
lot. this should prevent things that call afp_rename a lot from
causing problems.

also, what are people's feelings on the following behaviour with
programs like wordperfect that like to rename a lot?
      1) open a file. move that file somewhere else. copy another file
         with the same name to where the previous file was. now, save
	 that file from within wordperfect.

      2) if you're local, it will just rewrite that new file. 
      3) the current code i have in afpd won't let you do that as
         they're different files. wordperfect will get an error and
         save the temporary filename instead. 

note: i actually can make afpd do the same as the local case, but i
think the current afpd behaviour actually is more proper as it
prevents people from accidentally writing over files.

-a

---

From: PayPC System Mail Subscriber <[email-masked]>
Date: Tue, 29 Sep 1998 01:14:15 +1000

a sun said in [netatalk-admins] minor addendum at 26/Sep/1998 (Sat) 11:06:00.

> prevents people from accidentally writing over files.

Hrm.  I just noticed a bizarre thing with pre-9a.  I was using a System 7.5.3 
client OT 1.1.2 with both 3.6.1bd and 3.7.2 Ashare....  Ran ACT! 2.8 to open 
up some database on my netatalk server (running on Linux 2.0.33+)...  All 
attempts to open the database resulting in failures.  Even with wide-open 
directory permissions.  (I entered the .xxx extents into the SystemVolume 
type list too to be sure the filetypes were correct).

Now, when I first tried it...  the .xxx (extensions) were lowercase on the 
unix system.  ACT! complained it couldn't find a derivative file [with ACT!, 
you open up the .dbf file, and there are many auxiliary datafiles along with 
it, one of which is .mud -- ACT! says it doesn't exist (WHY?  I thought 
netatalk replicates the case-behaviour of the Macintosh) and tried to create 
it... leaving me with xxx.mud and xxx.MUD (OUCH!  What does this do to the 
Finder?!?!) -- so... I manually upcased the filenames.  Still no dice though.

All attempts to open fail.  So... I copy the VERY SAME files over to a 
macintosh (via netatalk no less!), enable file-sharing on that macintosh, and 
voila, it works.

Sooo....  I realise I should enable debugging and packet sniffing, but your 
posting made me wonder if it has something to do with filename resolution and 
related issues.  I was also SHOCKED that it let the Macintosh create a 
xxx.MUD file when then xxx.mud already existed.  How did it manage to do that?

PS: I'll be trying 10a later tonight.

PPS: One more (minor) pet peeve: I ran around for quite some time chasing the 
cause of a "passwd file has improper permissions" problem... turns out even 
though it may be rw-----, if the group of the .passwd file isn't the user's 
group, it dies.  I think that should be made a warning, since the file's 
still appropriately protected.  (read-write the owner only).  At the very 
least, the log-entry should be a bit more specific.  (I created a bunch of 
users' passwd files with root account and was a bit sloppy with some of their 
group ownerships (I left the group of the file set to root, though all 
permissions were read-write owner only).

By the way... I for one do not mind at all that I have different passwords 
for unix shell/ftp, samba, and appleshare access.  It lets me completely 
control the nature of the access I allow my users (extending the security 
granularity from where I would grant ftp, mail, telnet, etc, access all 
separately from one other).  I was also tickled pink that I could let the 
macintosh clients set their own password - something I haven't done w/the 
SAMBA ones yet, really.  It's more of a hassle there (chat debugging, 
scripts, etc).

=Rob=

Adrian: thanks so much for your work - it's made our Macintosh clients stand 
on nearly equal footing with our SAMBA ones.  Bravo!