Subject: Re: Please help: long filenames not showing up
From: Mike Fedyk (mikefe@bigfoot.com)
Date: Sat Aug 26 2000 - 23:27:01 EDT
> 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.
It seems that I wasn't clear in my assumptions you are referencing. I
wanted afpd to find files with names 32+ long and create a short
name. That short name would be stored in the .AppleDouble.
If we come across a new file that is 32+ we just add it to the list.
There would be no need to keep the mac users from seeing the file
until after a cronjob was run.
We can have a nightly cronjob that finds references to non existing
files that were removed by a samba/ftp/whatever user, and removes
them.
That brings me to another question. How does afpd deal with mac files
with a resource fork that are removed by a non-macos user? Do they
stay orphaned, or does afpd clean them up during the next listing of
that dir?
BTW, with the current solution (or should I say non-solution), you
would have to have a cronjob that runs fairly often to rename the
offending files. That is, if you don't want the admin to have to deal
with it every time it comes up. So, most any solution in afpd would
require a lot fewer resources than what we have currently.
> 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?).
Wouldn't that be in the libc, and not the kernel? Just like httpd in
the kernel, I don't think afpd should go there.
> 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)
What if we just rename the files? That way, everyone will see the
same name, and won't be confused by differing names. This can be
turned off with a config option if someone doesn't like remaming.
Then we would revert back to storing the short name in .AppleDouble...
If two files have the same short name, doesn't macos refuse to copy
the second file into the same directory? This would force the user to
deal with the naming conflict, just like normal.
Mike
This archive was generated by hypermail 2b28 : Wed Jan 17 2001 - 14:32:05 EST