This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

NTFS inode ouput from ls -i


I'm trying to reach Corinna. I have read many posts from her on the Cygwin forums that seem related to this topic. I hope this is the right email, please excuse me if it isn't.

I'm trying to find a tool, or way, that will allow me to point to a file and determine its cluster/inode/block quickly, without having to search through the NTFS MFT (or other structure that exposes file names). Under linux "ls -i" does this well. The "Sleuth Kit" forensic tool kit (TSK, by Brian Carrier) has a tool called "ifind" which can do this, but it takes forever, and I assume this is due to having to search through the MFT vs following the route the OS or Filesystem driver takes to access the file's content ($DATA stream) on the disk. The OS is able to locate the number of the inode-equivalent in NTFS quickly, and I'd like to be able to execute a command to do the same. Just like "ls -i" but for Windows and NTFS.

My question is related to the output of the "ls -i" command under Cygwin. Since NTFS doesn't use inodes, what is actually listed here in the output where the inode would be normally? Is it what the Sleuth kit refers to as an "MFT Number" (on this page http://wiki.sleuthkit.org/index.php?title=NTFS_Implementation_Notes). Or is it a Cluster Number, or Block Number, or NTFS File ID?

What would solve my problem is if "ls -i" under Cygwin produced a value that the sleuth kit tool "icat" could interpret as the inode-equivalent for NTFS. Right now under Windows/Cygwin when I run the ifind tool I get a different value from when I run "ls -i". Look at the following output. In this example I use the ifind tool and the icat tool from the Sleuth Kit. The ifind tool is typically used under linux to find the inode for a given file name. Under Windows the tool returns what the Sleuth Kit calls the MFT Number (which I think may be referring to the NTFS File ID) which is the NTFS inode-equivalent as far as the tools are concerned. I then use the icat tool to dump the contents of the file to the std out. Finally, I use Cygwin's "ls -i" to show what it is reporting as the inode under Windows on an NTFS partition for the same file.

mike@computer ~/test3
$ ls
file1

mike@computer ~/test3
$ cat file1
Hello!
123

mike@computer ~/test3
$ ifind -n /cygwin/home/mike/test3/file1 '\\.\c:'
195962

mike@computer ~/test3
$ icat '\\.\c:' 195962
Hello!
123

mike@computer ~/test3
$ ls -i file1
281474976906618 file1

mike@computer ~/test3
$

So the reason I'm doing all this, if you are wondering, is I'm hoping to create a tool/script that will output some of the contents of a file (ex: head file1) then do a secure delete/overwrite (e: shred -u file1), then verify the overwrite by checking the contents of the cluster/block with a tool like icat (ex: icat <file1's-cluster-number>). Essentially this is what I'd like to do (in the following example I use the Sysinternals tool sdelete to perform the overwrite as it tends to remove more information than shred under NTFS)

$CLUSTER=`ls -i file1`
head file1
sdelete file1
head `icat '\\.\c:' $CLUSTER

This wont work, however because the output of ls -i and ifind don't match.

Anyway, thank you for your time and a great piece of work in Cygwin. It is a fantastic project and accomplishment which has provided me, my colleagues, and students many years of good service.


Mike

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]