Subject: Long Filenames

From: "Derek J. Balling" <[email-masked]>
Date: Thu, 06 Apr 2000 11:21:37 -0700

This is going to sound silly, but has ANYONE had any luck with transferring 
files with long filenames over to the Mac?

I've got a bunch of CD-R's that I have stored my MP3's on (ripped them from 
my original media to use in my Empeg). I'm now retiring my Windows box and 
want to move them off the CD-R's and onto DVD-RAM discs, but a lot of the 
filenames are too long.

In a previous version of netatalk I looked at, if the filename was too 
long, the mac simply wouldn't see it at all (Where I would expect it to see 
like an abbreviated version of the filename or something).

I tried netatalk a month or two ago (what was installed on my SuSE 
install), and I've tried DAVE (from thursby.com) to try and transfer them 
that way (except DAVE bones the long filenames by transferring them as 
01PULP~3.MP3, using the 8.3 filename instead of working with the long 
filename to create something useful.

Anyone had any luck at all on this topic?

D

-----------------------------------------------------------------------
Derek Balling                                              408-530-5062
Technical Yahoo                                          Do You Yahoo!?

---

From: Matthew Geier <[email-masked]>
Date: Fri, 07 Apr 2000 09:02:47 +1000

> files with long filenames over to the Mac?

 By shortening the names :-)

> like an abbreviated version of the filename or something).

 The trouble I see is that then NetATalk has to deal with the possiblity
of duplicate names being created. It just cant chop >32 off with out the
very likely possiblity of duplicates. 

 The 8.3 code is Samba is a nightmare to look at. Not only has does it
have to make sure a name doesnt duplicate, but does the same thing each
time. Unlike the M$ operating systems that just store both forms of the
name on the disk, Samba has to re-run the short name generator each
time.

> filename to create something useful.

 That I expect is sensible behavour. The 'long' name is to long, request
the 'short' name from the server instead. The munged short name would
have been created by Samba on the server.

-- 
Matthew Geier			[email-masked]
Arts IT Unit			+61 2 9351 4713
Sydney University

---

From: "Derek J. Balling" <[email-masked]>
Date: Thu, 06 Apr 2000 16:43:14 -0700

>  By shortening the names :-)

Well, aside from that. ;-)

I've got a bunch of stuff on CD-R (that I can't easily rename for the 
obvious reasons), that I want to transfer, via netatalk or DAVE, or 
who-cares-what, over to the Mac. I'd put the CD-R's in the Mac directly, 
but there's no support for Joliet file extensions, which puts me in the 
same boat. :)

>very likely possiblity of duplicates.

Agreed. My thought was just to do a "Win95"-like munging. So that if I had
(assume these are longer, I'm too lazy to type *G*)

LongLongLongLongLong-Track1.mp3
LongLongLongLongLong-Track2.mp3

they would get munged to

LongLongLongLongLo~1.mp3
LongLongLongLongLo~2.mp3

or something like that.

>name on the disk, Samba has to re-run the short name generator each

Yuck.

>have been created by Samba on the server.

I would have it thought it would have been more sensible (well, to me, it 
IS more sensible *G*) to create an abbreviated name on the destination side 
using the longer name instead of the short-name.

That is to say, "give me the filename that most looks like what I last saw, 
given the OS restrictions of the OS I'm trying to operate within."

That's the logic I was using anyhow. :)

D

---

From: Ron Chmara <[email-masked]>
Date: Thu, 06 Apr 2000 17:12:40 -0700

> given the OS restrictions of the OS I'm trying to operate within."

<pedantic>
Why this is wrong: The short name is actually the file *name on most
95/98 disks*.
Joliet tries to override the filename, by using the comment field,
but, when given a choice between:
A) Joliet filename, stored on disk and in files....
OR
B) 8.3 filename, stored on disk and in files....

Your choices are often limited to what the actual _names_ are. That's why no
program is inventing a shortened version if the filename is *already* short.

So the files are never renamed, but the transferring OS has to read what it
_knows_ to be a filename. It doesn't invent anything, it just uses either
the file name, or the file comment. What you are talkng about is adding
a brand, spanking, new name, to replace the long comment. So then we're into
many "names", with an actual ISO/DOS filename, one OS/2 file comment,
(aka Joliet), and a _third_ name for MacOS 7-9, a fourth name for OS X
over AFP, and ext2 name (if it breaks any of the above...)

Hence, the lowest common denominator, the name most OS's can handle,
the 8.3.

Of course, many folks got so used to microsoft calling it a filename that
folks now seem to think it _is_ a filename. :-) 

-Bop

</pedantic>
--
Brought to you from iBop the iMac, a MacOS, Win95, LinuxPPC machine,
which is currently in MacOS land.  Your bopping may vary.

---

From: "Derek J. Balling" <[email-masked]>
Date: Thu, 06 Apr 2000 17:26:22 -0700

>program is inventing a shortened version if the filename is *already* short.

Well, that's PART of them, but the same problem/scenario exists where the 
file is on the hard drive as well. I'll grant you that the "kludge" is 
similar in both counts though. :)

>over AFP, and ext2 name (if it breaks any of the above...)

ext2 actually would probably be the most forgiving of them all. ;-)

And remember that we're talking about transferring the file. So you're not 
really "Adding" anything. You're replacing 
/(8.3-filename|>32character_long_filename)/ with /MacCompliantFilename/, 
and then, only on the destination host.

>Hence, the lowest common denominator, the name most OS's can handle,

Again, I'm not at all unclear as to WHY they did it, but (to my thinking), 
if I'm looking at the file, under windows, I see a 40-character filename. I 
don't see 8.3, I don't see anything else. That, to the user, is the 
filename. (Semantics aside about how it is stored and you only get 40, 50, 
80 characters through a monster kludge). If I transfer that somewhere, I 
expect to have something... well.... moderately CLOSE to what it started 
out as. ;-)

>folks now seem to think it _is_ a filename. :-)

Comments, by definition, wouldn't have to be unique. :) 
Implementation-level aside, it IS a filename. It's a unique identifier to a 
file. Whether that identifier is tied via a behind-the-scenes, one-to-one 
hash with an antiquated 8.3 filename, an inode-id, or what-have-you, I (and 
most people) view that as the filename. :)

D

---

From: Ron Chmara <[email-masked]>
Date: Thu, 06 Apr 2000 18:48:52 -0700

> and then, only on the destination host.

This has dire consequences for file tasks _based_ on filenames.
I'll give you an example: If you change the names for 340 images in a
Quark document during transfer, life gets real unhappy, real fast. :-)

>From another perspective: What names(s)do you back up to tape?

> Again, I'm not at all unclear as to WHY they did it,

Because Win32 is the only major OS left that is strapped down
to this.... :-) so it was a "see, we can do long names, even if it _is_
DOS/FAT!"

> but (to my thinking),

Yeah, something like an ISO filename truncation management standard would
be nice. Of course, do you really think MS is going to folow the standard? :-)

-Bop

---

From: Chip Mefford <[email-masked]>
Date: Thu, 06 Apr 2000 23:40:08 -0400

So Ron, Derrick, Mattew and lurkers;

I am in a pretty good place here. I am rolling
my little linux samba/netatalk file server out
into production and I get the chance to author
a company edict for future file nameing convention
amongst my mac and win folks. 

So, who has a good file nameing rule? 

what I have so far is shorter is better, always.
No punctuation marks save periods for extentions, 
no special characters save hyphens and underbars, 
and no spaces. (use underbars or hyphens as needed)

I think trying to force 8.3 would create rebellion.

---

From: Lutz Michaelsen <[email-masked]>
Date: Fri, 07 Apr 2000 09:21:29 +0200

> So, who has a good file nameing rule?

To avoid any possible problem, I advised all my users to use only:

* A-Z, a-z, 0-9, dot . and  _

* NO special characters like *, /, &, #, ...

* NO blanks

* Each file should have an extension (=>AppleVolumes.system) to detect the file
type on Unix and Windows.

* Each filename should have less than 32 characters (incl. extension)

* NO german Umlaute for filenames, like ä, ü, ...

Keep in mind, that the users can create filenames like "ls", "cd", "cat", ....
This could cause some funny results while working on Unix ... ;-)

Take care, that samba supports lower case/upper case. Check the filename
configuration of Windows.

It works fine for our little network with Linux, various Unixe,
Windows95/98/2000, and Mac 8.x/9.0.x

Regards,
Lutz

-- 
EASi-Engineering GmbH		Tel.	++49 (0) 89 / 1407-9872
Pelkovenstr. 81-b		Fax	++49 (0) 89 / 1407-9696
D-80992 Muenchen		eMail 	mailto:[email-masked]
Germany				WWW	http://www.easi.de

---

From: Patrik Schindler <[email-masked]>
Date: Fri, 7 Apr 2000 14:03:12 +0200

>files with long filenames over to the Mac?

Longer than 32 chars? You'll have to shorten them. The Finder cannot deal with larger names.

:wq! PoC

---

From: Patrik Schindler <[email-masked]>
Date: Fri, 7 Apr 2000 14:08:49 +0200

>Well, aside from that. ;-)

No chance. 32 chars per filename is a Mac limit you cannot override without source code from the Finder. :-)

Copy the disk(s) to a ext2 Filesystem and chop the files off to a shorter name with a combination of find, mv, cut and so on...

:wq! PoC

---

From: Patrik Schindler <[email-masked]>
Date: Fri, 7 Apr 2000 14:12:14 +0200

>So, who has a good file nameing rule? 

Use no umlauts and give the files an extension for windoze (this implies no more than 1 period in a file name). That's it. The rest is personal flavour.

:wq! PoC

---

From: Rich Martin <[email-masked]>
Date: Fri, 7 Apr 2000 09:35:14 -0400

One thing I have done to manage long filenames on a Mac is to place 
all the files in a Zip archive and give the archive a short filename.
-- 
   -- Rich Martin                       --= [email-masked] =--
      Data Wrangler, Planet Interactive