Subject: Re:[netatalk-admins]SOLVED! Renaming of Dirs when saving a file??

From: Mitch McNeel <[email-masked]>
Date: Tue, 15 Sep 1998 14:07:00 -0700

Solved!!

Solved two issues with one Solution.
Auto Backup and renaming of folder:

        I did some more testing and found that Quark is the cause of
renaming folders or Dirs...  Users use a feature called Auto Backup in Quark
that was causing the renaming of Dirs. (Folders).  I guess Quark Auto Backup
didn't know where to put the back up copy of the file the were trying to
save, so it renamed the folder to the back up copy of the file name thus,
causing the file not found issue when saving more then twice..  I had the
users disable this feature and everything worked just fine...  Each time
they went to save the file, it saved with no problems...  Hope this helps
other admin.'s/Users in the future.

Thanks for the replies.
Mitch

Michael M Han wrote:

> Previously...
> >        I have just upgrade to the newest version of Netatalk
> >pre-asun2.1.0-7a on a UE-450 running Solaris 2.6 with up-to-date
> >patches.  Users are now telling me that they are still having problems
> >with saving files (file not found -43 in QuarkXpress 4.03).  I just
> >found out that they are able to save the first two times, but on the
> >third try it gives them the error above.  Also, found on the third try,
> >it is renaming the folder where the file exists to the name of the file
> >they are trying to save.  Has anyone had this problem, is there a fix or
> >is this the causes of the no-fix DIRID's???
>
> I believe this is a non-fixed DID problem. In general, I attribute
> most errors that appear as problems locating directories or contents
> of a directory to DIDs. Still, there are a number of prepress sites
> running netatalk so I'd be surprised if this was a unique problem.
>
> Here's a breakdown of the DID deal: MacOS specifies that volumes
> catalog directories according with a unique numeric value. These
> values must be unique within the lifetime of the volume, so typically
> they are assigned in ascending order out of the specified 32-bit int
> (IIRC) field. DIDs are similar to inodes with the very big exception
> of uniqueness within the volume's lifetime. It's how MacOS
> accomplishes its magic with aliases and such.
>
> Anyhow, it seems there are numerous filesystem system calls in MacOS
> that use the DID to locate a filesystem entry (file or folder).
> Because netatalk cannot provide DIDs guaranteed to obey the Mac's
> unique-in-perpetuity rule (it's very complicated to implement
> correctly), netatalk just generates new DIDs every session. The thing
> is, within a single session (mounting to unmounting a volume) you
> shouldn't have trouble with DIDs. I've seen this sort of thing become
> a problem in the past though, so it's hard to say.
> _________
> mike ([email-masked])
> I will not defame New Orleans
>  - The collected wisdom of Bart Simpson
>