Subject: Re: [netatalk-admins] Syslog Message
From: PayPC System Mail Subscriber (spammail@quanta.paypc.com)
Date: Fri Oct 16 1998 - 02:02:39 EDT
a sun said in Re: [netatalk-admins] Syslog Message at 16/Oct/1998 (Fri)
10:50:00.
> I was just purusing my netatalk messages in syslog, and noticed one in
> particular that doesn't sound good, but I don't know what exactly it
> means. The message is afp_null handle 43.
>
> it means that afpd doesn't implement the FPCatSearch call. it's an
> optional call specified by AFP 2.1, so you can just ignore that message.
Hrm.... I realise the you'd probably need to do FileIDs and such for a
proper CatSearch, wouldn't you, but I've been thinking of implementing some
kind of FPCatSearch functionality... It and allias resolution are the only
things that really subtract from the netatalk experience. (Actually, though,
I give my uses a http file locator service so they can do hyper-fast file
searches so Catsearch for us isn't a major deal.)
My remaining issues with netatalk (I'm using 2.1.0 pre 10 under Linux 2.0.33+
w/Ashare IP clients all around)... is that for reasons unknown to me, I can't
make View changes stick on the root view of a share, even when the share
owner logs in. Also, sometimes when moving applications around and/or
changing file types en masse (Autotyper droplet actions, for instance) or
creating a directory in a large directory (>500 files) I'll get "Server
unexpectedly closed" messages... Don't get me wrong, netatalk is quite
stable, and I've never experienced data loss with it... but it has these
weird and impossible-to-reproduce little annoying gotchas.
What are peoples' best methods for keeping stray .AppleDouble entries under
control? Some of my shares are samba/mac -- and often samba users delete
files created by Macintosh users - which of course orphans .AppleDouble
files. 99% of the time, it's so minor it doesn't matter.
But my BOFH instincts despise having "chaff" in the system. I'm sure
someone's dealt with this before.
Also... I'm tempted to put together a patch to allow a share to be exported
that will prohibit resource fork creation (returning data that indicates an
empty fork) -- of course.... how badly will this freak out MacOS if I can
write data forks but not resource ones? (that is, returning a protErr on
resource addition attempts) Aside from the user confusion issues, what about
my just return noErr but not making the .AppleDouble entries? I dunno. I'd
definitely like to setup shares where .AppleDouble's aren't created all over
the place. It just looks icky.
=R=
This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:33:29 EST