Hi,
I was trying to list existing and removed files on my home pc to make timeline activity of fs but I came up with a bit of unusual output. I'm using TSK (v 4.1.3) and all I got is only Orphan Files
fls -r -d -F -f ext3 -o 244195328 /dev/sda
-/r * 16 $OrphanFiles/OrphanFile-16
-/r * 2368686 $OrphanFiles/OrphanFile-2368686
-/r * 2368692 $OrphanFiles/OrphanFile-2368692
-/r * 2368693 $OrphanFiles/OrphanFile-2368693
-/r * 2368694 $OrphanFiles/OrphanFile-2368694
-/r * 2368695 $OrphanFiles/OrphanFile-2368695
-/r * 2368696 $OrphanFiles/OrphanFile-2368696
-/r * 2368697 $OrphanFiles/OrphanFile-2368697
-/r * 2368698 $OrphanFiles/OrphanFile-2368698
-/r * 2368699 $OrphanFiles/OrphanFile-2368699
-/r * 2368700 $OrphanFiles/OrphanFile-2368700
-/r * 2368701 $OrphanFiles/OrphanFile-2368701
-/r * 2368704 $OrphanFiles/OrphanFile-2368704
-/r * 2368705 $OrphanFiles/OrphanFile-2368705
The output is actually huge so I'm not going to show it all here. To my understanding Orphan Files are files which still contain metadata information, but have no file names pointing to these structures. Also strange thing if I try to look for any inode information for any of these files MAC times are from 1970 to 2014, For some inodes "istat" shows that file was created on January 1, 1970 for others it shows valid time, March 2014.
inode 16282
Allocated
Group 1
Generation Id 0
uid / gid 0 / 0
mode ———-
size 0
num of links 0
Inode Times
Accessed Thu Jan 1 000000 1970
File Modified Thu Jan 1 000000 1970
Inode Modified Thu Jan 1 000000 1970
inode 16
Not Allocated
Group 0
Generation Id 797506347
uid / gid 0 / 0
mode rrw——-
Flags
size 0
num of links 0
Inode Times
Accessed Thu Mar 27 115833 2014
File Modified Thu Mar 27 115833 2014
Inode Modified Thu Mar 27 115833 2014
Deleted Thu Mar 27 115833 2014
Can anyone explain why do I have output like this? I have another ext3 image which I created myself, but everything looks fine there with valid file names and times (both for existing and deleted files) .
inode 16282
Allocated
Group 1
Generation Id 0
uid / gid 0 / 0
mode ———-
size 0
num of links 0Inode Times
Accessed Thu Jan 1 000000 1970
File Modified Thu Jan 1 000000 1970
Inode Modified Thu Jan 1 000000 1970
This looks like zeroes everywhere. Perhaps a deleted inode, as Ext3 wipes inodes on file deletion (normally, at least). The inode number, allocation status and group nr are – I'm pretty sure – not part of the inode on-disk format.
The next inode is shown as unallocated yet partially populated. My initial guess would be an inconsistency between the inode bitmap and the actual state of the inode. Or perhaps inodes may be deleted without wiping in some circumstances. Assuming the filesystem has not been exposed to other file system implementations.
Is the file system sound? Or does it contain inconsistencies? Bad blocks? Can you identify such inconsistencies? Are any of the inodes you mentioned affected?
If you are looking at an unsound file system (or even an unsound disk drive), you can find anything.
This looks like zeroes everywhere. Perhaps a deleted inode, as Ext3 wipes inodes on file deletion (normally, at least)..
What do you mean exactly? The whole inode data structures? As far as I know, on file deletion ext3 marks inode and data blocks unallocated (obviously) and wipes direct or indirect block pointers, but all other inode information (MAC times, type, link count, etc) should be intact. FS looks fine and I don't have any problems now, but a few months ago I got some error saying that os couldn't mount /tmp directory or something (don't quite remember now), and just a few days ago my whole os crashed but afterwards it worked just fine. Also some of the files were wiped with general GNU shred utility and it renames file to zeroes before deleting, so maybe this could be a factor (but still only a few files were wiped with shred).
Anyway I will update this tomorrow because checking the whole system takes time, maybe I just really do have some general file system problems.
Update I checked for bad blocks, corrupt data in superblock (although if there would be any bad data in superblock I would seen it by now), journal, no errors. File system looks good and is in a clean state.