Subject: Re: Please help: long filenames not showing up
From: Franz Dürr (fduerr@gmx.de)
Date: Tue Aug 22 2000 - 05:16:41 EDT
> Can we store something more in the .AppleDouble for this purpose?
> Maybe we could even have symlinks in there with the appropriately
> short name point to the actual file contained in the .AppleDouble's
> parent dir? Just make a nightly cron job to deal with the dangling
> symlinks from windows delete/renames and you're set.
>
Mike,
the problem with storing short names permanently (say, in the AppleDouble
directory) is to keep it in sync with changes to file names applied by
non-atalk-clients. I think, users would not accept it, if you tell them:
'Hey, just wait a day and you'll see that file'. And watching the
directories permanently would be a waste of resources.
To do it cleanly, you would have to apply hooks in the kernel's create,
rename and unlink, so what you end up with, is basicly a kernel mode afpd
(perhaps not a bad idea anyway?). If you want to avoid that, creating short
names 'on the fly' is IMHO the second worst solution. To distingish files
that have the same short file name in a persistent manner, you could include
the inode-numer in the file name (problem: Different short file name after
file copy into a different directory) or a hash based on the creation date
(same problem, if you don't preserve the creation date when copying) or a
hash / checksum íd based on the complete name (problem when two names result
in the same id, persistency lost in this case). That id would have to be
appended in any case, regardless whether the short name is unique or not.
The need to encode a 32+ file name will probably be relatively rare, so I
think, it can be accepted if one non persistent file name turns up once in a
year or so.
Admittedly no perfect solution, but probably fast and easy to implement.
Just my Euro 0.0223 (= $0.02)
This archive was generated by hypermail 2b28 : Wed Jan 17 2001 - 14:32:02 EST