Subject: Files not visible with over 31 characters

From: [email-masked] (Lee Blevins)
Date: Thu, 14 Jun 2001 18:11:14 -0400

I have users ftp files to our ftp site.

If they send from a pc and the filename is over 31 characters, it's
invisible the the mac when opening the ftp folder that is being
published by netatalk.

Why does name truncation not seem to be happening here?

---

From: Carsten Neumann <[email-masked]>
Date: Fri, 15 Jun 2001 00:50:46 +0200

> Why does name truncation not seem to be happening here?

What name truncation do you expect?
Please tell detailed rules!

---

From: David Nelson <[email-masked]>
Date: Fri, 15 Jun 2001 11:20:56 +0000

> 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

---

From: Mac Conin <[email-masked]>
Date: Fri, 15 Jun 2001 19:06:27 +0200

hmm,

what about this:

run an apache on the server, do a simple webpage with a
simple form containing a button à la 'check for incoming
files' By pressing the button a perl script scans the
directory and moves the files to the work zone. This
script could also check for illegal characters or missing
.extensions by analysing the files as far as that makes
sense.

-- 
--schnippe-di-schnipp-- 

mit freundlichen grüssen

-----------------------------------------------------------
Mac Conin                        EUC Online Service GmbH
Geschäftsführer                  Taubengasse 9
[email-masked]                    D 50676 Koeln
http://www.euc.de                HRB Köln 32038
tel : +49-221-923 27 33          fax : +49-221-239 651
-----------------------------------------------------------

---

From: Steven Karel <[email-masked]>
Date: Fri, 15 Jun 2001 13:10:21 -0400 (EDT)

On Fri, 15 Jun 2001, David Nelson wrote:

> end of the name to get it down to 31....

I agree not handling >31 character filenames is a nuisance. But users also
get muddled when file names change, so I wouldn't rate it as a high
priority.

David's rules seem ok if they can be codified into an algorithm for
naming.

By the way, there must be existing code for this. mkisofs (mkhybrid) will
correctly create HFS filesystems with unique names from a directory with
long filenames in which the first 31 characters match (I just tested it).
If someone thought this was a priority and wanted to work on it, I assume
there's code that could be ported over to use as a starting point.

steven

---

From: Danny Sauer <[email-masked]>
Date: Fri, 15 Jun 2001 14:37:59 -0500

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

---

From: Danny Sauer <[email-masked]>
Date: Fri, 15 Jun 2001 14:51:25 -0500

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... :)

---

From: [email-masked] (Lee Blevins)
Date: Fri, 15 Jun 2001 16:56:27 -0400

> > 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....
> 

It can make netatalk unuseable for allowing Mac's to see files in an ftp
server. 

I don't understand why this exists. A Mac connected to a win2k server
doesn't have this problem. 

I have installed Services for unix on my win2k server. I think I'll nfs
export dir from the freebsd box and mount it on the win2k and see if I
can then share it via Services for Macintosh.

Convluted I know but consider my alternative.

I have a business we don't like having to ask customers if they're
ftping from a mac or a pc and to limit them in their file names.

It's just bad business.

It's this kind of limitation that makes IT managers use Sun and Helios.

I would hope you and the others involved with netatalk see that this is
really a priority since it's a "deal killing" bug. I know we don't pay
for this but seriously, it should be the best it can  be.