Subject: Re: [netatalk-admins] minor addendum
From: PayPC System Mail Subscriber (spammail@quanta.paypc.com)
Date: Mon Sep 28 1998 - 11:14:15 EDT
a sun said in [netatalk-admins] minor addendum at 26/Sep/1998 (Sat) 11:06:00.
> 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.
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!
This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:33:19 EST