Holding the assumtion that of the 2 forks, file and resource, file will
always be huge, and resource small (small is relative) then as long as the
OS deals with the file fork and tells netatalk what it has done with it,
and hence allows it to process the resource fork, it should be safe.
If like you say moveandrename is atomic, then great, that just means the
resource fork needs to be moved and renamed. No bigie.
I suspect you're making this out to be a more fatal problem than it realy
On Sun, 24 Mar 2002, didier wrote:
> Steve Freitas wrote:
> > > Silliness aside, one thing we really really need to keep in mind, is
> > > that in our efforts to create the WunderAFPServer we need to be
> > > sensitive to other services such as Samba, FTP, shells, CVS, DAV,
> > > HTTPD's etc that also may be accessing this space. We lose the power and
> > > flexibility of *IX's if we make Netatalk and its file management so
> > > micromanaging that some poor soul over FTP who moves a file around ends
> > > up icing a folder/tree for the Mac users. It would almost be better to
> > > implement such cataloging at the filesystem layer as, for example
> > > metadata in a fast, robust filesystem like XFS (call it XFS+ if you'd
> > > like) so that the tools can make the same system calls they always have,
> > > and let the filesystem deal with ID's and such. I'm not shooting down
> > > CNID or its progeny, just injecting a bit o' reality into a thread that
> > > *seems to* be moving towards an "our toys over all else" direction.
> > > "Seems to" is the key there. I can be wrong.
> > I agree with you in principle that using a metadata-supporting filesystem
> > would be the correct solution, but making Netatalk filesystem-specific will
> > narrow its applications too much. Most admins won't be willing to do all the
> > admin work necessary to move to XFS/Reiser4/whatever just to support one
> > service.
> > That's why I think it makes sense to use a filesystem-level trigger
> > (imon/fmon/whatever) with a persistent Netatalk process to manage
> > .AppleDouble and CNID issues. Then Samba/FTP/shell/DAV/NFS will, without
> > modification, not impair the integrity of the Netatalk-specific metadata.
> Too bad, I'm afraid it doesn't work.
> If you want a reliable file server you need that an afp call,
> moveandrename (unix rename) is atomic, or it WILL corrupt files by
> design. With afpd by implementation you get resource fork and data fork
> Without os help, I think it can only be done with a modified userland
> nfs server:
> at boot time afpd and nfsd are started so they access the native
> the exported tree is locally nfs mounted for Samba/FTP/shell/DAV access.
> Sure copying files with open, read, write won't give the right result,
> but it will be 100% reproducible.
> Netatalk-devel mailing list