I posted this in General, but i got absolutely nothing so I'll give it a shot here and see if anyone has an idea...

Ok, I like to transfer and sync files between my slackware machines via 100MB Zip disks because I currently do not have a home network setup. I realised awile ago that the linux ext2 file system was totally butchering long file names, so as making backups of my /home directory impossible without compression into a tar.gz file (which i dont want to do).

... so i started using the msdos vfat file system by mounting -t vfat and this seemed to preserve the file names just fine, but after swapping disks back and forth a few times it looks like the file names got butchered again!

Does anyone have an idea of what exactly causes this scrambling of file names? Could I have accidently mounted the disk incorrectly at some point?

thanks

My first thought is that Linux never butchers filenames. I'll mention the following because many newcomers to Linux do not know that it is case sensitive. Linux is case sensitive like all *nix operating systems. For instance consider the following filenames.

aBcDeFg
AbCdEfG
Abcdefg
abcdefg
ABCDEFG
abcDefg

These are all totally different filenames, all though they all contain the same characters the case is different in each of them. It only takes one character difference, even a space, to create a different filename.

Now is your differences just on the zip disk backup or on the hard disks as well as the zip disk? Can you identify when the corruption is occuring? Can you post some of the corrupted filenames?

Yeah, I didn't think so either... but it happened. I should explain that they werent "butchered" at first.... more like truncated sorta MSDOS style...

gaim-0.59.8.tar.gz becomes gaim-~.gz or something like that

It was doing that when i formatted a zip disk to ext2 under linux and copied files over to the disk, so i started using the standard FAT 16 format under windows (which turns out to be the 4th partition under linux - hdd4, sda4, ect.) and mounting it -t vfat.

Well, that all worked just fine (long file names were retained). I could go back and forth from linux to zip to windows to zip, whatever with files like CoolUtility-0.149-4985.tar.bz2 or whatever.

The "butchering" occured when i used that dos formatted zip disk to transfer files between two seperate linux machines. after mounting on the laptop (which uses a parallel-port zip drive), i copied files from it and when i mounted the disk back on my primary machine, files were all hacked to nearly-unrecognizable shreds.... sorta like

gaim-0.59.8.tar.gz becomes )0oaim-mmm.gz

a few characters remain, but the rest is ridiculous nonsense. I will try to recreate this atrocity when i get the laptop set up again.

For now though, any ideas?

A possibly-related note :

when copying a file to the IDE Zip drive on my primary machine (under linux... X Windows... su as root) I get a chown error, however the file still copies over.

The description would appear that the problem is on the notebook with the parallel port zip drive.

The only thought I can really offer from your description would be to make sure that you do not connect a printer to the zip drive on the notebook. When Iomega developed that unit, most printers were not bidirectional type winprinters. The data transfer could be corrupted by a connected printer.

If you only need to READ the zip on the notebook then perhaps mounting read-only would work around the problem.

I suppose there could be a driver issue on the notebook. However, I have never used a parallel port zip in Linux. I have not had any problems with IDE and USB interfaces though.

I would also warn as well, if the disk is being corrupted in the filenames then I would also highly question the data that is transferred. To verify files before and after transfer you might to look at a program called "md5sum" (man md5sum). I think it should detect any changes or corruption. The md5 sum could be transferred in a file on the zip as well. Or md5sums for the entire disk should also be possible.

All zip drives that I have had will lock so that you cannot remove it until the disk unmounted. That is to insure that all buffers are actually written before the media is ejected. So I wouldn't think this would be the problem.

Well maybe it has been of some assistance.
Good luck tracking it down.

Thanks for the input.

However, the Butcher of File Names has struck again. I mounted the parallel-port zip on the laptop last night and copied a few files over. No problem.

I just booted the machine and mounted the drive... only this time it's screwed up.

the directory "malevolus" has become "mameoou1"

however, everything INSIDE the directory seems to be ok. So, it appears to only be affecting the root directory.

the four files that were also in the / directory of the zip disk are also hacked to pieces.

gaim-0.59.9.tar.gz has become gaim=0^?1.zz

the other three files (two .bz2 and one .mp3) are also scrambled.

I havent copied any files onto the disk from my laptop.... just from my main machine (Linux w/ IDE Zip drive), and when i mounted the first time on the laptop everything was ok... so it doesnt appear to be the mounting process that is screwing it up... At some point in the unmounting of the parallel port zip interface maybe?

There is no printer attached.

So my problem (1) Only effects the root directory of the zip disk
(2) occurs at some point during unmounting
shutdown.

So how does "Unmounting Remote File Systems" with Slackware work? Is it the same as me just unmounting all the drives manually before a shutdown or reboot? Could that be part of the problem?

Another interesting note to this :

Slackware was installed to the laptop from a Zip disk. I have the 8.1 iso copied to the zip disk (sans X, GNOME, KDE, etc.) and trimmed down under 100 MB.

During install, the system is booted with the iomega.s kernel that includes parallel-port Zip support, Install is loaded from the five floppies and copies directly from the Zip.

During this process the parellel port drive is mounted and unmounted, however, the Slackware install files are not corrupted at all.

You can always unmount the drive manually using the "umount" command. Just provide the moint point as the argument. (umount /path/to/zipmedia)

But I would concentrate on the par port drive first. Use a blank zip disk. Partition, format etc. Copy anything to it, /usr/bin for me is about 106 MByte, just lots of files in the root directory. Then unmount it. See how long it takes to actually write everything. Then mount it again and see if it looks OK or not. Another command I have used that does not go through the mount/umount is the "dd" command.

dd if=/dev/input_device of=filename.img

Use it while the disk is not mounted. Without the partition ID number at the end of the device. It reads the disk from beginning to end. If you have the disk space available. The image can then copied to another disk and then mounted to see if it is corrupted. Or you can use the "cmp -l" command with the device name and the filename as the arguments to see if they are different.

I use the "dd" command to backup my notebook 30 GByte hd with multiple partitions and operating systems to a 40 GByte hd connected through the firewire port. Simply reverse to restore it. I made a boot CD that has everything needed based on the Live CD provided with Slack 8.1 boxed set.

If you use the device partition ID number as the value like you would for a normal mount command, then the partition will be read and the image can then be mounted under loopback.

mount -t ext2 -o loop /path/to/filename.img /mount_point

For the type above you could use vfat or as required. You can then review it to see if it is corrupted.

This process just verifies the proper operation of the unit. All the commands above have available man pages if you need more info.

If I understand what you wrote earlier about your process then I am suspecting the shutdown procedure may be shutting down before all the buffers are actually written because the par port drive is so slowwww. And it may be that manually unmounting the disk and waiting for it to complete may resolve the issue and prevent the corruption.

Cheers.