Subject: Re: Disappearing files.....
From: Mike Johnson (ffp_randjohnson@yahoo.com)
Date: Mon Dec 04 2000 - 12:46:38 EST
A most excellent explanation!
This problem has been the one thing that has kept me from really using
netatalk, and I'm sure that I'm not the only one. Especially in a samba
and netatalk environment, it doesn't take much imagination to think of
how many directories could be changed / moved / deleted without afpd
knowing about it.
If there is any way to patch this / fix this I'm sure many, many people
would be extremely grateful!
- Mike
>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<
On 12/4/00, 8:58:46 AM, Netatalk <atalk@abarrach.franken.de> wrote
regarding Re: Disappearing files.....:
> On Thu, Nov 30, 2000 at 12:49:22AM -0000, lists-mail wrote:
> > Periodicly I will hear a complaint from a developer that they have lost
> > permissions on a mounted directory. I have them unmount the volume and
remount
> > it, the problem disappears. Within a few hours, files-entire directories
will
> > disappear. As in gone, without a trace, vamoosed.
> >
> > I'm currently pulling down the syslog and messages files from the server
to
> > search for clues.
> >
> > Has anyone else been experiencing this? Today we lost several hundred
files
> > and an entire days code. I gotta fix this, I've started each developer to
a
> > local disk backup policy until I can solve the problem.
> Hi,
> My 10c on the disappearing files problems ...
> 1st: the Mac does store some information from a mounted volume. When I
unmount
> and mount a volume under Mac, on mount the Mac clearly requests some
items
> from this folder that are not fetched from the volume. Some of my patches
> to netatalk make this clearly visible:
> Dec 4 09:46:14 server2 afpd[10506]: ASIP session:548(2) from
x.x.x.x:2051(0)
> Dec 4 09:46:14 server2 afpd[10506]: login xx (uid x, gid x)
> Dec 4 09:46:51 server2 afpd[10506]: afpd: did de44->16d33
> Dec 4 09:46:52 server2 afpd[10506]: afpd: did 16d33->2ca73
> Dec 4 09:46:52 server2 afpd[10506]: afpd: did 2ca73->2
> Dec 4 09:46:52 server2 afpd[10506]: afpd: did 29ad9->16d33
> Dec 4 09:46:53 server2 afpd[10506]: afpd: did 26b34->16d33
> This is an example of a mount from a Mac. The volume is mounted at
startup.
> Now the Mac requests a directory id (DID) of 0xde44. If the afpd visited
> the directory with this DID before, line 3 should never occur, so the Mac
> really stores information about the volume on its own. The lines show
that
> this DID is resolved correctly down to root-level (DID 2), as are two
other
> directory lookups, both not in afpds directory cache.
> That this directory is resolved correctly is due to my patches to afpd.
> On a normal base afpd, the lookup would've failed, forcing the Mac to do
a
> full lookup on the complete directory path, part by part. So no problem
here?
> Maybe not ... as afpd (at least the versions I looked at) is known to
> reuse the DIDs it gives out between sessions, this scenario might happen:
> - afpd hands out DID 456 which the Mac stores ... the Mac then unmounts.
> - another session removes directory corresponding to DID 456 and creates
a new
> directory somewhere completely different which just happens to be
assigned
> the same DID by afpd.
> - Mac 1 now mounts again, looks around some directories, chances upon #
456,
> caches its DID, and then, when the Mac does a lookup on DID 456, finds
the
> new directory _without the Mac noticing_ it got the wrong one.
> - what happens now if the user of this Mac now deletes that directory ?
> This might account for some of the file loss problems some people seem to
> experience. The window between 1 and 2 and between 2 and 3 could be
> arbitrarily large. The Mac seems to store DIDs for a long time, even
> when their resolving fails.
> Solution: never reuse DIDs
> CU
> Roland Schulz
> atalk@abarrach.franken.de
This archive was generated by hypermail 2b28 : Wed Jan 17 2001 - 14:32:43 EST