Subject: Re: Disappearing files.....
From: BWS - Offwhite (brennan@offwhite.net)
Date: Mon Dec 04 2000 - 14:17:47 EST
I believe you can compile Samba to be Netatalk aware. It will then move
and delete the .AppleDouble files properly, or so I have read.
Brennan Stehling - web developer and sys admin
projects: www.greasydaemon.com | www.onmilwaukee.com | www.sncalumni.com
Do you ever find it is easier to explain an idea if you put it into
Star Trek terms?
On Mon, 4 Dec 2000, Mike Johnson wrote:
>
> 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