6

I see ghost files in red colour inside some of my directories:

[drey@cyan|23:54|~/downloads]ls -la
ls: cannot access teamviewer9_linux.deb: No such file or directory
total 1318096
drwxrwx--- 1 root plugdev       8192 Sep 30 23:32 .
drwxrwx--- 1 root plugdev       4096 Sep 25 14:06 ..
drwxrwx--- 1 root plugdev       4096 Aug  6 15:04 fl
-rwxrwx--- 1 root plugdev 1329594368 Sep  2 00:24 linuxmint-17-mate-32bit-v2.iso
-rwxrwx--- 1 root plugdev   20118938 Sep 30 23:32 skype-debian_4.3.0.37-1_i386.deb
-????????? ? ?    ?                ?            ? teamviewer9_linux.deb
[drey@cyan|23:54|~/downloads]ls -la teamviewer9_linux.deb 
ls: cannot access teamviewer9_linux.deb: No such file or directory
[drey@cyan|23:54|~/downloads]

I think it can be some type of disk failure, should I use fsck --force?

  • How did I create them?
  • How can I get rid of them?

    $ smartctl -a /dev/sda

didn't show any serious failure symptoms (5,197,198,199 all equal zero).

P.S.: I've tried touch /forcefsck and reboot. Now I have unreadable downloads dir:

[drey@cyan|18:44|~]ls -l ~/downloads
lrwxrwxrwx 1 drey drey 16 Feb  8  2013 /home/drey/downloads -> /data/downloads/
[drey@cyan|18:45|~]ls -l ~/downloads/
ls: reading directory /home/drey/downloads/: Input/output error
total 0

/data is NTFS partition:

/dev/sda3 on /data type fuseblk (rw,nosuid,nodev,allow_other,default_permissions,blksize=4096)

NTFS check gone good:

[drey@cyan|18:52|~]sudo ntfsfix /dev/sda3
Mounting volume... OK
Processing of $MFT and $MFTMirr completed successfully.
Checking the alternate boot sector... OK
NTFS volume version is 3.1.
NTFS partition /dev/sda3 was processed successfully.
  • It is normally a permission issue. if you do recursively chmod on the that directory to fix it. (ie. chmod 0777 ~/downloads) – Raza Sep 30 '14 at 15:33
  • 3
    @Raza If it's a directory permissions issue, why can he list all the other files in the directory? – Barmar Sep 30 '14 at 15:46
  • 1
    I think it's corruption, maybe fsck will clear it up. – Barmar Sep 30 '14 at 15:48
  • 2
    @Raza - This is not a permissions issue. If you do not know the answer to Q's please do not guess or assume things that you do not fully understand. Bad advice can lead to ppl damaging things that may be recoverable! – slm Sep 30 '14 at 16:10
  • 2
    @peterph - understood, but running that chmod may cause further damage, it's best to not advise unless your sure, or to say, "I think". – slm Sep 30 '14 at 16:23
6

This usually indicates that the filesystem, specifically the meta data pertaining to that particular file has become corrupt. You could try performing a fsck on the disk, but I'd suggest doing this with the filesystem unmounted.

Using /forcefsck

You can usually schedule a check at the next reboot like so:

$ sudo touch /forcefsck
$ sudo reboot

Using shutdown

You can also tell the shutdown command to do so as well, via the -F switch:

$ sudo shutdown -rF now

NOTE: The first method is the most universal way to achieve this!

Using tune2fs

You can also make use of tune2fs, which can set the parameters on the filesystem itself to force a check the next time a mount is attempted.

$ sudo tune2fs -l /dev/sda1
Mount count: 3
Maximum mount count: 25

So you have to place the "Mount count" higher than 25 with the following command:

$ sudo tune2fs -C 26 /dev/sda1

Check the value changed with tune2fs -l and then reboot!

References

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.