2

My co-worker sent me a theme in a tar.gz file and I tried unzipping it using the archive manager GUI as I usually do for any kind of zipped file. However, it produced a corrupt file/directory that I can no longer delete.

Note that the working directory is in a directory I created in my home folder.

ls -l produces

???????????  ? ?        ?       ?            ? Alt_Elementary_Dark

Right click properties menu says that the permissions could not be determined, and all info is 'unknown' (like size,accessed,modified)

Type is said to be 'Binary (application/octet-stream)', though it should have been a directory.

What I've done to try and remove:

$ sudo rm -rfv Alt_Elementary_Dark
rm: cannot remove ‘Alt_Elementary_Dark’: Permission denied

$ sudo rmdir Alt_Elementary_Dark 
rmdir: failed to remove ‘Alt_Elementary_Dark’: Permission denied

$ sudo touch Alt_Elementary_Dark
touch: cannot touch ‘Alt_Elementary_Dark’: Permission denied

$ mv Alt_Elementary_Dark renamed_to_remove
mv: cannot stat ‘Alt_Elementary_Dark’: Permission denied

$ sudo mv Alt_Elementary_Dark renamed_to_remove
mv: failed to access ‘renamed_to_remove’: Permission denied

$ sudo ls -ld Alt_Elementary_Dark
ls: cannot access Alt_Elementary_Dark: Permission denied

Is there some other way I can remove this corrupt, unknown directory?

Improve this question
10
  • It looks like the filesystem does not have any information about the file. Try running touch on the file: touch Alt_Elementary_Dark Commented Jun 6, 2016 at 17:40
  • 1
    in order to remove a file you need write permissions on the directory, not the file itself. What are the permissions on the working directory? Commented Jun 6, 2016 at 17:47
  • @Elixiroflove touching provides the same permission denied results Commented Jun 6, 2016 at 20:00
  • 2
    I almost think you might want to run fsck on that filesyste. You also see output like above if there is filesystem corruption. Commented Jun 6, 2016 at 20:24
  • 1
    Is your home directory accessed via NFS? And what's the output from lsattr? Commented Jun 6, 2016 at 20:39

5 Answers 5

Reset to default
3

First check the permissions of the directory the file's in.

The ls -l output where all except the file name are question marks matches a case of having read permission (= allowed to read the directory listing), but no x permission (= not allowed to access the files within the directory).

After adding the full rwx permissions for yourself for the directory, I think you'll find the ls -l listing will be normal, and then you'll also be able to delete the file normally.

Improve this answer
0

try to rename it and after that remove it.

Improve this answer
1
  • Also gives no permission, I added those attempts above Commented Jun 6, 2016 at 17:43
0

If it is associated with (application/octet-stream) it is probably a print file of some sort (gs, ps, or pcl). There are a lot of possibilities, but if you go to the cups interface or /etc/cups you should be able to see the print jobs. One is probably stuck and was moved there when a script when wrong.

Do you use any sort of PS to PDF type functionality? This could also push it there.

Improve this answer
1
  • This file has persisted over restart so I don't believe it to be a stuck job of any sort. I also don't think this has to do with postscript to pdf because it should have just been a directory that got unzipped, there are no pdf's in what the directory should of contained. Commented Jun 6, 2016 at 21:25
0

i have one of thease files but thats by the by not a solution but hopefully more information gaind stat the file command as follows sudo stat then file path leading to file /sometdirectory /somedirectory /somedirectory /alt_elermentry dark in this case,

but it would be whatever file you could not read its permissions placed at end of path

directory =folder (type exsactly what you see as path ) the forward slashes seperate the folder exsample /etc/ajaxterm or some directory /some file

Improve this answer
1
  • It's unclear what you are proposing as the answer. Commented Aug 24, 2022 at 17:25
-3

Do sudo chmod ugo+rwx -R . (on the working directory). Also check for IO errors in dmesg.

Improve this answer
3
  • I don't think this is the route, this is my home directory on the network so I don't want to mess with permissions (I probably can't even do this as it is managed elsewhere) Commented Jun 6, 2016 at 21:27
  • sweeping commands like this introduce more problems than they solve. And if the user is not able to delete these files or move them, what makes you think that he can change the ownership of these files ? Commented Jun 6, 2016 at 21:42
  • I am not suggesting to change his home directory permissions, he said he was in another directory beneath ~. To delete a file you need wx on its parent directory (and maybe r too). Commented Jun 7, 2016 at 5:53

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.