Score:2

Attempting to clone a musical instrument HDD but all file names are shortened to 8 characters when viewed in Ubuntu Studio 20.04

ua flag

Edit: Thank you all for the suggestions! It has given me a lot to chew on. I guess I'll start with refining my original question: I am at present trying to browse directories on a hard drive via Ubuntu Studio 20.04, but am unable to read file names in anything but 8.3 format, whereas the original format of naming supports 16 characters.

It has been posited that the additional 8 characters could rely on some process specific to the original equipment (not Ubuntu) to unlock the longer filename, which would be a stopping point of sorts.

I have copied the 42MB drive in this manner [sudo dd if=/dev/sdd of=a path to the USB drive to a file named 42MB.dd I had created beforehand. The 42MB.dd file was written, but I am unable to scrutinize it with testdisk as all I can see are physical drives, not virtual (?) drive images.

I've run into difficulty simply burning the 42MB.dd image onto a CDR. As it is reasonable that if the image can be burnt without losing whatever secret sauce results in 16 character names that I do not need to be able to look at the directory with Ubuntu. That said, I have not exhausted myself yet, so I'll continue to dig away at this from these new and highly helpful angles.

/Edit

Edit part 2: I have not tried disk2file, because their website is disabled; and I have yet to try WinHex as it looks like it's a windows product and I'm wary of adding another layer of potential complication to my process.. but it's not ruled out by a long shot (I have just installed wine).

I have now been able to open the disk image with TestDisk. It appears as if the 8.3 format is baked in from there as well. I did have to "rebuild" the boot sector of the disk image to see this.

Screen capture of TestDisk displaying a column of identically named different files

I have not yet tried to steer TestDisk onto the original hardware, as I don't want to break anything, yet.

Many thanks for all of the ideas and effort. It may be that I just have to pare 20 years worth of inter-dependent file names down into eight character chunks. Nothing drastic before a few nights of sleep though.

/edit part 2

I have a stack of external SCSI hard drives that have been used with and formatted by an Akai MPC2000 MIDI sequencer/sampler. My aim is to clone these drives into back-up files so I'm no longer relying entirely on old storage.

I have a 42MB drive to start with. When I mount this drive all of the file names appear as 8 character plus extension, whereas the MPC naming convention is 16 characters plus extension. Since a lot of the files are audio samples saved from a particular source, many of the files read as the same name when truncated to 8 characters (and the same file size, which is incorrect - though I believe that will be resolved when file names are complete).

I used dd if="my drive" of="USB thumb" to grab the data. This effectively turned a 16GB USB stick into the spitting image of the 42MB drive - complete with the truncated file names.

I would like to be able to see the data on the drive (or drive clone) complete with 16 character names and accurate files sizes before I archive and move on to the next, larger drive. Any suggestions?

cn flag
Ray
I don't know what the MPC2000 is, but I was curious about your problem and Googled around. Seems [others](https://www.mpc-forums.com/viewtopic.php?f=1&t=29794) have faced your problem... One person said [this](https://www.mpc2000xl.com/fatvsmpc.htm). Seems that Akai uses a long filename format that even predates Microsoft's use (I learned something new!). I guess you can try Googling around by adding the model with the words "file system". Seems to me to be a proprietary. If Akai opened up their format, perhaps you can find someone who did something to solve your problem...good luck!
crochambeau avatar
ua flag
Thanks Ray! So it sounds like Ubuntu might just see these as DOS files and my visibility gets forced through an 8 character window. I suppose I will proceed with trying to burn this image to a CDr in hopes that the read format error I appear to experience will not taint the raw data, and that the Akai will still be able to read it. I see there is an emulator that claims linux compatibility, perhaps I will give that a go as well.
cn flag
" When I mount this drive all of the file names appear as 8 character plus extension" the issue would be with the mount options. Please add it to the question. "Normal iso9660 filenames appear in a 8.3 format" though that FS almost only got used for CD and some DVDs and not for SCSI :P edit: oh they even had their own filesystem and it was also called `MPC`
cn flag
Sorry can't find anything. I would assume they created their own version of a iso9660 format (that is the only 1 I know that uses the 8.3 format) It might have an internal database with a conversion tool to get from short to long name (like a predecessor of metadata).
Alejandro avatar
jp flag
I can't improvise a precise list of test steps right now, but you can create an image file of the full 42MB drive with `dd if=/path/to/drive of=./image.dd`, and then try to use TestDisk with the image and try different filesystem parameters to recover the full filenames.
waltinator avatar
it flag
Investigate the drive (or the copy) with `sudo file --keep-going`. [Edit] your question, don't respond via Add Comment.
Alejandro avatar
jp flag
Did you try WinHex or disk2file as suggested here? https://www.mpc2000xl.com/fatvsmpc.htm
Alejandro avatar
jp flag
Also, if I recall correctly, to open an image.dd with TestDisk, just add the path of the image to the command: `testdisk /path/to/image.dd`
Alejandro avatar
jp flag
With that output of TestDisk I would think that it is seeing the different size of each file. Maybe you can copy them one by one with the `c to copy the current file` option, renaming them once they have been copied to your system.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.