Now I have two directories which cannot be deleted or moved even by root. I cannot neither change ownership nor permission of these directories as well. I've removed everything else from that partition, leaveing only these two directories, run zerofree, compressed an image and uploaded it to dropbox. You can check that with the following: cd /tmp wget https://dl.dropboxusercontent.com/u/22701362/broken.tar.xz tar xvf broken.tar.xz mkdir test sudo mount broken.iso test cd test More details are here: http://askubuntu.com/questions/794262/undeletable-directory-in-lostfound
Please tell me that this is reproducible at least
Sorry. I've missed 'append only' attribute on a parent directory
The undeletable directory also has the inline_data flag set, even though the filesystem doesn't ==> possible memory bitflip?
(In reply to Darrick J. Wong from comment #3) > The undeletable directory also has the inline_data flag set, even though the > filesystem doesn't ==> possible memory bitflip? Was that question addressed to me? Sorry, I don't think that I can help with the answer. By the way, while one from askubuntu.com has success with removing both directories with removal of attributes from them, I was able to remove only one directory with that way. the second doesn't even let me see attrbutes set on that dir: http://askubuntu.com/questions/794371/lsattr-permission-denied-while-reading-flags-on-directory
I think that there still could be a bug since I am not able to read directory attributes: http://askubuntu.com/questions/794371/lsattr-permission-denied-while-reading-flags-on-directory
Grief , your inode or directory content is empty. It is corrupted also. I got this after fixing your #1589030 with debugfs and changing fields directory permissions, flags to 0x1000 from your invalid value and also changing the modify time stamp to current value from 2032. I think this is a case where your inode field values has been corrupted or overwritten due to some error/failure accidently. Fixing that or opening in debugfs write mode solves the problem. Please close this as it doesn't seem to be related to ext4 . If you can reproduce this using a test case from standard utilities or other ways accessing API's please submit the test case/code. You could go ahead and dd/write a byte that changes some struct field in the ext4 and when broken.iso is loaded it displays errors for one/few inodes. Unless done properly with valid values , it is not supported i guess. ./1/plexus-component-annotations-1.5.5.jar.sha1: total 8 drw-rw--w- 2 47469 268482890 4096 Nov 13 2014 . drwxrwxr-x 3 47433 47433 4096 Jan 13 17:02 .. ./2: total 12 drwxrwxrwx 3 root root 4096 Jul 7 22:31 . drwxr-xr-x 5 root root 4096 Jul 3 20:21 .. drwxrwxrwx 2 root root 4096 Jul 7 21:48 #1589030 ./2/#1589030: total 8 drwxrwxrwx 2 root root 4096 Jul 7 21:48 . drwxrwxrwx 3 root root 4096 Jul 7 22:31 .. ./lost+found: total 8 drwx------ 2 root root 4096 Jul 7 20:44 . drwxr-xr-x 5 root root 4096 Jul 3 20:21 ..
Navin, thank you for finding the time to look and answer! I'll follow your advice and close this. But in this case, I'd like to understand, isn't it the bug of fsck that it didn't fix that? Also, I'll give debugfs a try, however, I've never used it before.
Isn't it the bug of fsck that it didn't fix that ? Yes and No. Yes when the bug can be legitimately reproduced from calling API/exported functions with valid values or with tools and commands. No when you have corrupted values in images due to incorrect writes or flushes by device or binary etc. Maybe fsck can be modified in this particular case of i_flags which are valid and rest all invalid. You will have to check on linux-ext4 list whether it is such a value or not. Also if possible provide a patch later.