2

A picture is worth a thousand words, so I want to start with that:

The Impossible File

From the image you can see that I have a ~500GB hard drive. The filesystem is ext4. On this 500GB hard drive, I have a file that is over 74TB.

I'd love to know how this is possible (obviously some type of disc corruption), but more importantly I'd like to know if the file is safe to delete with, say rm .npmignore, or if there is another way to get rid of it that would be equally effective.

I'm mainly worried about destroying the data on my disk that follows the start of the impossible file.

For the curious, this file was buried in a repository under the path node_modules/bower/node_modules/request/node_modules/qs/.npmignore. After moving the file out of the directory and performing a git checkout .npmignore, I discovered the file really was a text file (duh), and was in fact less than 700 bytes.

  • 1
    en.wikipedia.org/wiki/Sparse_file – jordanm Apr 15 '15 at 22:21
  • 4
    Note: The file size in the screenshot (47278999994559) is kind of an interesting number: 0x2B00000000BF. All those zeros make it look like a single corrupted byte, if the original size might have been 0xBF (191 bytes) – user41515 Apr 16 '15 at 1:10
  • Excellent observation! I looked up the size of the original file, and it was exactly 191 bytes. Well done, sir! – JoBu1324 Apr 16 '15 at 15:20
  • I should ask, then - if the problem is as you say, a corrupt byte in a file size indicator somewhere, is it safe to delete? that sounds different than the sparse file explanation that everyone else is jumping on. – JoBu1324 Apr 16 '15 at 15:22
2

Your file system is very unlikely to be corrupted. Ext4fs, like most Unix file systems supports sparse files, i.e. files which have some of their blocks not backed by any physical media and which blocks by convention are returned as containing only null values (zeroes) when read.

Removing a sparse file represent no specific risk, outside the fact it might contain data that some process or people doesn't want to be lost.

You can use the strings command to get an idea of what actual payload a sparse file contains.

If you really suspect your file system to be corrupted anyway, the best way to figure it out would be to unmount and fsck it.


Edit: according to your last comments to your own question, it looks like your file system is corrupted after all. Removing a file, or doing anything on a file system that shows sign of corruption is risky and might corrupt it further. I would strongly recommend to unmount it as soon as possible and perform a fsck to make sure no other metadata is corrupted.

0

It should be "safe" to delete the file; it is a config file of sorts, telling npm what files and patterns to ignore when you are doing whatever you are doing with npm.

Whether you want to delete it or not depends on you. It may be serving a useful purpose. Maybe cat it and see what it contains, and then make a judgement call from there.

As @jordanm points out, the file is not actually 47TB.

  • 3
    Both ls -al and wc will state the file is 47 TB, not to mention the useless cat and wc will take ages to "read" the file. – jlliagre Apr 15 '15 at 23:00
  • 1
    But ls -sl or du will quickly show the allocated size of the file on disk. – BowlOfRed Apr 16 '15 at 21:39
0

As Wumpus Q. Wumbley pointed out, there was either a corrupted byte or a whopper of a co-incidence. I decided to bite the bullet and delete the file, which went smoothly with no apparent damage to the surrounding files.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.