Re: Files not visible with over 31 characters


Subject: Re: Files not visible with over 31 characters
From: Danny Sauer (dsauer@teleologic.net)
Date: Fri Jun 15 2001 - 15:51:25 EDT


Replying to myself... Ignore the crud about the map file. I had the 31
char limit on the wrong side of the hub when I was typing... :)

Danny wrote regarding 'Re: Files not visible with over 31 characters' on Fri, Jun 15 at 14:44:
> 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