Subject: Re: Files not visible with over 31 characters
From: Danny Sauer (dsauer@teleologic.net)
Date: Fri Jun 15 2001 - 15:37:59 EDT
Why not just steal a method from windows? If the filename's greater than
31 chars, start the truncation at the far right if there is no extension
or if the rightmost extension has more than 4 chars. If the filename has
an extension with 1, 2, 3, or 4 chars, it's probably for some program's
compatibility, and truncation should begin just left of that extension.
One more char should be removed from the section being truncated and
replaced with a 1. If that filename exists, increment the number. When
0 is reached (after 9), move one position to the left, and start the process
over again, recursively, until the filename is unique. I really don't like
the idea of removing from the front or middle of a filename, 'cause the
middle takes a little more math to find than the end, and the front would
screw up alphabetical sorting.
After that, map that name to the original long name with some sort of
indexed map file (dbm or something would be ok). That way, netatalk
can present the long name to the mac clients, and *nix/windows clients
still get the reasonably truncated name.
I imagine that something would have to be done to uniquely identify the
files in the case that they were renamed/moved by the *nix side or by a
samba user or whatever. A client program to look in the DB and find
files that used to be mapped but no longer exist might work too - maybe
keeping the file's creation time and mime type with the original name
would help to fix broken mappings. At worst, if the mapping breaks, the
filename after truncation will still be reasonably readable by all clients.
--Danny
David wrote regarding 'Re: Files not visible with over 31 characters' on Fri, Jun 15 at 11:38:
> On Thursday 14 June 2001 10:50 pm, Carsten Neumann wrote:
> > What name truncation do you expect?
> > Please tell detailed rules!
>
> Okay. This is how I would like to see file name truncation handled:
>
> If the name is over 31 chars and there is no extension just lop chars off the
> end of the name to get it down to 31.
>
> If the file name has an extension or layers of extensions e.g.
> complete_collection_of_scanned_john_denver_album_covers.tar.gz, then start
> lopping just to the left of the first extension. The file name from my
> previous example would become:
> complete_collection_of_scanned_john_denver_albu.tar.gz
>
> Of course sometime removing characters from a file name will result in the
> file having the same name as another file in the same directory. For example
> consider what would happen if the following files were both 1 character
> over the Macintosh limit of 31.
> my_really_important_files1.tgz
> my-really_important_files2.tgz
>
> Both files would end up with the name my-really_important_files.tgz, if that
> were allowed. The best way to handle this situation may not be immediately
> agreed upon by all.
>
> A number could be added to the end of the file name between the root and the
> extension. The example file names would become:
> my_really_important_files.tgz
> my-really_important_file1.tgz
>
> The characters could be removed from the beginning or the middle of the file
> name. Which would result in something like this:
> y_really_important_files1.tgz
> y-really_important_files2.tgz
>
> OR
>
> my_really_impotant_files1.tgz
> my-really_impotant_files2.tgz
>
>
> The best solution might be a combination of these approaches.
>
> First try removing chars from between the root of the name and the file
> extension.
>
> If that results in a conflict try removing chars from the middle of the name.
>
> If that results in a conflict try removing chars from the beginning of the
> name.
>
> As a last resort add a number to the file name.
>
>
> I look forward to hearing other peoples' thoughts on this.
>
> Have a great day.
> David Nelson
>
This archive was generated by hypermail 2b28 : Sun Oct 14 2001 - 03:04:42 EDT