I have a newly acquired external 300GB USB2/Firewire drive, formatted so that it will mount on both Macintosh and Windows computers. As a matter of fact, I've transferred files from both Windows and Macintosh machines onto the drive using both USB and Firewire. This works fine.
I also have a stack of CDs I burned on a Windows machine.
I'm sitting in front of a Mac OS 9 machine. Said machine truncates filenames longer than its 31 character limit.
I want to transfer files from the CDs to the drive without having their filenames truncated. I believe my options are to upgrade the machine to OS X, or to find another machine.
Am I mistaken?
Thanks in advance for answers.
I also have a stack of CDs I burned on a Windows machine.
I'm sitting in front of a Mac OS 9 machine. Said machine truncates filenames longer than its 31 character limit.
I want to transfer files from the CDs to the drive without having their filenames truncated. I believe my options are to upgrade the machine to OS X, or to find another machine.
Am I mistaken?
Thanks in advance for answers.
(no subject)
Date: 2005-10-06 08:56 pm (UTC)Good luck!
(no subject)
Date: 2005-10-06 09:12 pm (UTC)(no subject)
Date: 2005-10-06 09:12 pm (UTC)(no subject)
Date: 2005-10-06 09:13 pm (UTC)Unfortunately, that's just about correct. To make matters worse, I believe Classic MacOS isn't savvy to file extensions, so that's the information you're most likely to lose.
Have you considered putting the files on a MacOS X machine, whacking together a Perl script to make the filenames manageable, and doing new CDs? Depending on just how many CDs we're talking here, that will almost certainly be less painful than the upgrade to OS X. (-:
Good luck!
(no subject)
Date: 2005-10-07 12:24 am (UTC)The definition of kHFSMaxFileNameChars as 31 is a real heartbreaker here - allowing 3 characters and a period for the main extension leaves only 27 characters of play, which means the "easy" way to do this ( hash each file with a message digest algorithm ) would require something that hashes into thirteen or less bits, because it needs to be made human readable. If this wasn't necessary ( i.e. you could have high characters in the file names ) you could use SHA-1. I don't think this is a very good idea - and I can't think of any good hashes which fit this criteria!
If you can get all the files in one place, it would be possible to sequentially number them with a python script, thus -
import os;
import string;
counter = 1;
for r, d, f in os.walk( os.curdir ):
for filename in f:
oldname = os.path.join( r, filename );
chunks = filename.split( os.path.extsep );
if( len( chunks ) <> 1 ):
newname = "%020x%s%s" % ( counter, os.path.extsep, chunks[ -1 ] );
else:
newname = "%020x" % ( counter );
os.rename( os.path.join( r, filename ), os.path.join( r, newname ) );
counter += 1;
This won't rename directories, just files.
p.s. Thanks for blowing away my tabs, lj, you meanie. :-(
(no subject)
Date: 2005-10-07 01:39 am (UTC)it out of band, so the OS isn't involved. This would entail writing a program that
directly read the Rock Ridge (or High Sierra, or whatever) file names from the
volume label on the CD, and handcrafted the filesystem entries on the hard drive.
While I am quite capable of writing such a monstrosity, I don't think it's a
reasonable solution. I have several machines that dual-boot MacOS 9 and X,
works pretty well.
(no subject)
Date: 2005-10-07 01:46 am (UTC)Whoops! I meant to say 13-byte! Thirteen byte hash expanding to 26 bytes worth of printable hexadecimal.
(no subject)
Date: 2005-10-07 04:52 am (UTC)(no subject)
Date: 2005-10-07 05:14 am (UTC)http://www.tempel.org/joliet/
(no subject)
Date: 2005-10-07 06:20 pm (UTC)(Embarrassingly, I don't have a classic Mac around any more for experimentation. Not since the terrifying upgrades to the iBook...)
(no subject)
Date: 2005-10-07 07:33 pm (UTC)