0 byte file size and lost chains with 200GB firewire drive

[eviscerate]

I'm using scp in knoppix to dump data from IBM A31 laptops to a 200 GB external WD drive attached via firewire to a Dell gx150 running ssh in knoppix. As of last friday, I noticed that many files copied to the external drive were 0 bytes. The entire directory structure copied intact as well as the file names, only the data is not linked to the file. The exact size of the data being copied is reflected in the decreased free space on the destination drive. When deleting the entire directory containing the flawed copy, only a portion of the expected space is freed. I first noticed this issue when there was about 60 GB free space left. With all the corrupted transfers and ineffective deletions, free space dropped to about 28 GB. At this time, I threw an internal drive in the gx150 and imaged it to winXP which also reported 28 GB free on the external 200 GB drive but reported the sum of all that data as only about 112 GB. I then ran chkdsk /f on the firewire drive; after deleting the lost chains, I regained almost an additional 50 GB of space. What could be happening? I've spent some time googling (may not be looking in the right place) for anything related to my problem. I found a grand total of one post that describes a similar situation (but no resolution) which I have pasted below.

Subject: Linux and VFAT/FAT32 limitations
Newsgroups: uk.comp.os.linux
Date: 2003-08-18 04:03:44 PST

Are there any limitations to the size of a VFAT filesystem on a
FAT32 partition under Linux? The reason I ask is that I have a
250GB Firewire disk with a single partition on it and a wopping
great FAT32 filesystem on it. Has to be that way as I need to
share it between Linux and Windows 2000.

All was fine until very recently. Now whenever I create a file
on the disk using Linux it ends up with a zero file size, and
if I check the disk under W2K, there are a whole host of lost
chains (well one for each file created to be precise)

The only thing that I can think of is that disk is now over half
full (139GB out of 232GB to be precise). Has anyone else come
across this problem?

[Dave_Bechtel]

--My advice is to repartition the drive to 120 +80, or maybe 100/100 would be better. Actually after repartitioning, I'd reformat as well. Fat32 is compatible, yes; but I think it wasn't really designed for huge drives. I have an internal 80-gig in my system but have never tried partitioning it to 1-huge-Fat32. (I keep Windows small, and store all my large files in Reiserfs.)

--IIRC kernel 2.4.22 has something like a 120-Gig Fat32 limit. This may go up with kernel 2.6, I'm not sure. Google ("linux fat32 partition limit") sez it's 128GB, but why push things:
http://linux.org.mt/article/filesystems#N10059

--Scp - make sure you're using protocol 2 and the blowfish cipher, it should speed things up a bit. You might want to md5sum/check the files on Firewire as well after the copy is done.

I'm using scp in knoppix to dump data from IBM A31 laptops to a 200 GB external WD drive attached via firewire to a Dell gx150 running ssh in knoppix. As of last friday, I noticed that many files copied to the external drive were 0 bytes. The entire directory structure copied intact as well as the file names, only the data is not linked to the file. The exact size of the data being copied is reflected in the decreased free space on the destination drive. When deleting the entire directory containing the flawed copy, only a portion of the expected space is freed. I first noticed this issue when there was about 60 GB free space left. With all the corrupted transfers and ineffective deletions, free space dropped to about 28 GB. At this time, I threw an internal drive in the gx150 and imaged it to winXP which also reported 28 GB free on the external 200 GB drive but reported the sum of all that data as only about 112 GB. I then ran chkdsk /f on the firewire drive; after deleting the lost chains, I regained almost an additional 50 GB of space. What could be happening? I've spent some time googling (may not be looking in the right place) for anything related to my problem. I found a grand total of one post that describes a similar situation (but no resolution) which I have pasted below.

Subject: Linux and VFAT/FAT32 limitations
Newsgroups: uk.comp.os.linux
Date: 2003-08-18 04:03:44 PST

Are there any limitations to the size of a VFAT filesystem on a
FAT32 partition under Linux? The reason I ask is that I have a
250GB Firewire disk with a single partition on it and a wopping
great FAT32 filesystem on it. Has to be that way as I need to
share it between Linux and Windows 2000.

All was fine until very recently. Now whenever I create a file
on the disk using Linux it ends up with a zero file size, and
if I check the disk under W2K, there are a whole host of lost
chains (well one for each file created to be precise)

The only thing that I can think of is that disk is now over half
full (139GB out of 232GB to be precise). Has anyone else come
across this problem?