[Netatalk-admins] Re: cnid and dbpath

[Thomas S. <tsc...@us...>]

Hello Andy, thanks for your message!

Let's see if I can give you some pointers to get your
Netatalk back in good shape:

> i found a thread where you wrote about having a differeint path
> for the cnid database.

Yes, and I'm still keeping cnid DBs separated from sharepoints
for different reasons -- AFAIK, if disks get filled up to the max,
cnid DBs will become corrupted if residing at the same partition
the shares are residing at. Additionally, by hosting DBs on another
disk, I can achieve significant performance gains at my rather low end
server box. And, that way cnid DBs won't interfere with disk quotas.

> i currently have a problem with my netatalk 1.6 on a redhat 8
> box with 4 mountpoints on an ext3 fs.
> when users open their freehand files on the server and try to
> add pictures via import, they always get leaded to
> their "Desktop Folder" on the local mac.
> on a different server (same rh 8 and netatalk 1.6) with one
> single sharepoint, freehand doensn't have this problem.

Duh, I lack any experience with Freehand, but I remember similar
wired behavior of QuarkXPress while toying with 1.5pre releases
back in summer 2001.

Most likely, at your problem server, two or more sharepoints have
the same creation date/time. Side note, AppleTalk clients distinguish
between different remote shares by creation time, not by path or name.

For a quick test, mount all four Netatalk shares at a Macintosh
workstation, do a "get info" for each share. Creation time must be unique
for each share. 

If not -- the file "Icon^M" at the root level of each sharepoint holds
creation time info. You need to delete (or move to a backup folder)
a single "Icon^M" file at a time, login from a Macintosh, logout,
delete "Icon^M" at the next share, login, logout, and so on, to achieve
unique creation times. Note, that way you're likely to break references
to placed files for each and every already existing Freehand file.

> do you have any ideas how to fix the problem or  is storing
> the cnid db to another path a bad idea.

For storing cnid DBs to another path -- there isn't a single
problem report I'm aware of. You did provide a distinct DB path for
each sharepoint !?!

If problems persist, I'd recommend to join Netatalk admins mailing list
<https://lists.sourceforge.net/lists/listinfo/netatalk-admins>
as you can see I alredy CC'd to the list address, hope you don't mind.

Good luck!
-Thomas