Subject: [netatalk-admins] Problem with nested folders

From: "Kimon Tsinteris" <[email-masked]>
Date: Sat, 01 May 1999 15:20:54 -0400

Hello,

Out of curiosity, does netatalk represent nested folders slightly
differently than how a regular Mac AppleShare server would?

This is the current problem. My linux box is acting as a file server for a
Powerbook. I store files of large size on the file server to free up space
on my laptop. This includes my digitized music. However, any playlist I may
make only loads correctly while my Mac remains on. Upon a reboot (and
re-mount of the AppleShare file server) the playlist only will load mp3s
from the root folder. Any sorted in nested folders just will not load... it
appears it just does not find them where the playlist instructed it to look.

Any ideas what could be causing this?

Many thanks,
Kimon T.
[email-masked]

---

From: Stefan Bethke <[email-masked]>
Date: Mon, 03 May 1999 11:17:59 +0200

Kimon Tsinteris <[email-masked]> wrote:

> on my laptop. This includes my digitized music. However, any playlist I
> may make only loads correctly while my Mac remains on. Upon a reboot (and
> from the root folder. Any sorted in nested folders just will not load...
> it appears it just does not find them where the playlist instructed it to
> look.

Your playlists probably use alias records to reference the mp3 files.
Because aliases on sub-folders on a volume use the folder's (directory's)
ID, and netatalk can't support that ID in the underlying file system, the
ID changes with each session.  Now, you mp3 player looks for
"my-favorite.mp3" in folder ID 123, which either doesn't exist in this
(subsequent) session, or is a completely different folder, where there is
no "my-favorite.mp3".

Most people believe the major difference between Macintosh files and all
other file formats would be the data and resource fork.  Where a file
server is concerned, another feature is quite more important: File IDs.

A File ID is a number assigned to a file or directory when it is first
created.  The ID stays the same for the file, whatever you do with it,
until the file is deleted.  Even after that, the ID isn't reused for
another file until the namespace wraps (32 bits ~= 4 billion files).

Because most file systems have no support for a number like that, or even
if they do, there is no API to access it, all AFP file server software has
to either make up the IDs as directories and files are encountered, and
remember the IDs assigned for the session (netatalk, some older versions of
Novell), or store the ID<->path relation in seperate files (most commercial
netatalk clones).  Windows NT is an exception: NTFS has a file generation
number (whatever MS calls it, I don't know), and SFM uses it.

As I understand it, Adrian Sun is preparing support for fixed (stored in a
seperate file) directory IDs for -2.1.4. This might solve your problem.
*However*, when using a seperate ID-to-path table, you must be *very*
careful to keep this table up-to-date at all times, or you Macs might get
confused really badly.

Stefan

--
Mühlendamm 12           |  Voice +49-40-256848, +49-177-3504009
D-22089 Hamburg         |  e-mail: [email-masked]
Germany                 |          [email-masked]