Subject: Re: Disappearing files.....
From: Netatalk (atalk@abarrach.franken.de)
Date: Mon Dec 04 2000 - 11:58:46 EST
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