Unable to delete or stat file

Support & Help Requests
#1

I know this is pretty much a newbie question, but I'm stumped. I moved a bunch of files and folders from and external drive to my internal RAID, but one folder and one file remain (although the same file appears on the target). A mv <source> <target> throws the following error:

mv: cannot stat 'filename.ext': No such file or directory

I have tried using sudo, chmod (to make it universally rwx), chown (to make sure ownership was set), rm -f, rmdir on the parent directory, and even using ssh to connect externally and trying a remove. No matter what I try, I keep getting the "can't stat" message.

I'm going to unmount the external drive and remount it (that's worked in the past for some "ghost" items), but I'm curious about this.

1 Like
#2

This means that the file does not exist (anymore).

There is a probability that 'gvfs' forgot to update its internal filelistings which results in 'ghost files' that, in reality, are no longer there.

i.o.w: The by gvfs percieved filelistings are sometimes out of sync with reality.

It happens to me sometimes with downloads:

  1. During download a downloaded file is often saved as 'example.ext.part'
    When the download is finished it gets renamed to 'example.ext'

  2. Sometimes I seem to have an 'example.ext.part' file and an example.ext file which is complete bogus.

In reality the download.ext.part file is, ofcourse, no longer there but caja doesn't seem to know that yet. Forcing Caja to reload the directory fixes it.

I haven't encountered it with external drives yet. If reloading the directory doesn't help then an unmount followed by a remount will (use the disk-tool-gui).

When 'gvfs' is tripped up by stale/incorrect cache data you also might try to empty the gvfs-cache by issuing the following command from the terminal and see if this helps to get 'gvfs' reread the filesystem:

rm $HOME/.local/share/gvfs-metadata/*
1 Like
#3

I get what you're saying @tkn. Usually, if I have remnant '.part' files they are zero-byte and easily removed. I've had occasions when a local "file" exhibits this behavior, and Caja doesn't remove it even on reload. Rebooting my server usually fixes that problem, but that strikes me as being a bit extreme.

Oddly enough, I solved the problem by mounting the drive to my Mac and then just dragging the file and folder to the Trash, and emptying it. Gone. Everywhere!

1 Like
#4

Caja gets its info from 'gvfs' , i think this is serious enough to file a bug here:

I couldn't find the same bug in the list so you might file a new one.

b.t.w.: This might be an interesting read:

Also this link to an old bug has one interesting comment:
https://bugzilla.gnome.org/show_bug.cgi?id=597017#c2

To quote comment 2:

I guess i can see one possibile leak, if you have sensitive filename and then delete the file not using gio there could be a leftover reference to the filename. Is this what you worry about?

Which in this case means: if you have a file and then delete the file not using gio there could be a leftover reference to the filename.

And that clould be (maybe) comparable to what you describe

1 Like