Correcting ext3 File Corruption?

An anonymous reader asks: "I am looking for ext2/ext3 expert. I have a small file (1395 bytes) that appears HUGE when runing ls -l (70368744179059 bytes [yes, that's 70 terabytes]). This causes a problem because tar wants to back up all those extra bytes. We have back ups of the file else where, but I'm afraid to delete it. When I remove it what is going to happen to the file system (Kernal version is 2.4.18 on i686). This seems to be a pretty bad math error on the part of the file system. This is a really weird error, but could just be the issue of a corrupted sector on the drive. Has anyone else seen this before and have any ideas as to whether such files can be recovered? Is this problem just a small glitch or an omen of an impending filesystem crash?

"Here's what the files look like on the system:

[ root@secure parse]# ls -l HTMLFrameSet.class
-rw-rw-r-- 1 root devel 70368744179059 Mar 20 09:05 HTMLFrameSet.class

[root@secure parse]# wc HTMLFrameSet.class
15 58 1395 HTMLFrameSet.class

...and the error message from tar:

tar: HTMLFrameSet.class: File shrank by 70368744169331 bytes; padding with zeros

No wonder my backups didn't finish! :-)"

Comments

dd

[Yarn]

As you know how long it is supposed to be:

dd if=[file] of=[new file] bs=1 count=[length]

I strongly suggest rebuilding the affected filesystem, that kinda weirdness can be indicative of deeper problems.

Re:This is a sparse file....

[ivan256]

While what you say about sparse files is generally true, that's probably not what this is. This is probably a single bit error on this guy's hard drive. There's probably more of them, but he noticed this one because it popped up in a noticeable location. The hard drive is probably on the way out, or he's got some faulty memory (if it's ECC, otherwise this could just be a fluke).

Tar does deal with sparse files correctly, and if this were one, he wouldn't be having trouble.

Deletion question

[obtuse]

I think you're right about the flipped bit. Copy the file with dd, specifying the right output size.

I'd bet there are problems with the whole filesystem, but to continue with what he asked:

It seems to me that he should be able to rm the file without any worries, after making a good copy. Only the inode that points to the falsely enlarged file will be removed, and the data blocks won't be touched, right?

If there is other data in the misallocated blocks, that dat should either have its own references, or it's already as good as deleted anyway.