NTFS inode ouput from ls -i

NTFS inode ouput from ls -i

[Harry G McGavran Jr]

I just had to deal with the output from chkdsk on my Windows 7 pro
that lists MFT record numbers just like ifind and icat do
in the Sleuth Kit as summarized in:

https://cygwin.com/ml/cygwin/2012-11/msg00172.html

The chkdsk MFT record numbers are exactly what ifind and icat
display/use. I also discovered when doing "ls -i" on NTFS
file systems mounted on my Ubuntu 16.04 linux system that
the "ls -i" numbers reported are the same as the chkdsk, ifind, and icat
record numbers.  These are all the lower 32 bits of the 64 bit
numbers reported by "ls -i" with the current cygwin.  Had
the cygwin "find -inum" and "ls -i" used these 32 bit numbers,
my task would have been easier.  From the above link, Corinna
found it odd that ifind and icat would use the 32 bit numbers.
I would have preferred them when dealing with chkdsk issues.

What's the current thinking about this?

Harry



--
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

Re: NTFS inode ouput from ls -i

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1996 bytes --]

On Jul 17 11:44, Harry G McGavran Jr wrote:
> I just had to deal with the output from chkdsk on my Windows 7 pro
> that lists MFT record numbers just like ifind and icat do
> in the Sleuth Kit as summarized in:
> 
> https://cygwin.com/ml/cygwin/2012-11/msg00172.html
> 
> The chkdsk MFT record numbers are exactly what ifind and icat
> display/use. I also discovered when doing "ls -i" on NTFS
> file systems mounted on my Ubuntu 16.04 linux system that
> the "ls -i" numbers reported are the same as the chkdsk, ifind, and icat
> record numbers.  These are all the lower 32 bits of the 64 bit
> numbers reported by "ls -i" with the current cygwin.  Had
> the cygwin "find -inum" and "ls -i" used these 32 bit numbers,
> my task would have been easier.  From the above link, Corinna
> found it odd that ifind and icat would use the 32 bit numbers.
> I would have preferred them when dealing with chkdsk issues.
> 
> What's the current thinking about this?

The descriptions I found describes the NTFS FileID as a combination
of the 16 bit sequence number with the 48 bit file record number(*).
Stripping off 16 bits sequence number would be ok, but stripping the
upper 16 bit from a 48 bit record number sounds bad.

OTOH, the maximum number of files on an NTFS volume is restricted
to the number of clusters, which is 2^32-1.

If it's *safe* to assume that the record number corresponds with
the cluster number, ok, but I'm not sure this is the case.  I never
use really big filesystems with Windows.  This would need testing.

But then there's another problem.  The 64 bit file ID can also be
used to open a file by ID.  Stripping the upper 32 bit from the
value disallows to use the file ID in that way.


Corinna

(*) http://digitalresidue.blogspot.de/2016/02/getting-started-with-sleuth-kit-pt-3.html

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: NTFS inode ouput from ls -i

[Harry G McGavran Jr]

On Jul 18 3:50, Corinna Vinschen wrote:
>On Jul 17 11:44, Harry G McGavran Jr wrote:
>> > I just had to deal with the output from chkdsk on my Windows 7 pro
>> > that lists MFT record numbers just like ifind and icat do
>> > in the Sleuth Kit as summarized in:
>> > 
>> > https://cygwin.com/ml/cygwin/2012-11/msg00172.html
>> > 
>> > The chkdsk MFT record numbers are exactly what ifind and icat
>> > display/use. I also discovered when doing "ls -i" on NTFS
>> > file systems mounted on my Ubuntu 16.04 linux system that
>> > the "ls -i" numbers reported are the same as the chkdsk, ifind, and icat
>> > record numbers.  These are all the lower 32 bits of the 64 bit
>> > numbers reported by "ls -i" with the current cygwin.  Had
>> > the cygwin "find -inum" and "ls -i" used these 32 bit numbers,
>> > my task would have been easier.  From the above link, Corinna
>> > found it odd that ifind and icat would use the 32 bit numbers.
>> > I would have preferred them when dealing with chkdsk issues.
>> > 
>> > What's the current thinking about this?
>
>The descriptions I found describes the NTFS FileID as a combination
>of the 16 bit sequence number with the 48 bit file record number(*).
>Stripping off 16 bits sequence number would be ok, but stripping the
>upper 16 bit from a 48 bit record number sounds bad.
>
>OTOH, the maximum number of files on an NTFS volume is restricted
>to the number of clusters, which is 2^32-1.
>
>If it's *safe* to assume that the record number corresponds with
>the cluster number, ok, but I'm not sure this is the case.  I never
>use really big filesystems with Windows.  This would need testing.
>
>But then there's another problem.  The 64 bit file ID can also be
>used to open a file by ID.  Stripping the upper 32 bit from the
>value disallows to use the file ID in that way.
>
>
>Corinna
>

Thanks for the thoughts and info -- based on that info, personally, I'd
go for returning the bottom 48 bit file record number. That is
apparently what ntfs-3g developers felt was appropriate under linux
(Ubuntu 16.04 at least) and would allow people chasing down chkdsk
issues to make using cygwin find and ls easier.

    Harry



--
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

Re: NTFS inode ouput from ls -i

[Corinna Vinschen]

On Nov 23 08:12, Peter Rosin wrote:
> On 2012-11-22 22:08, Michael Lester wrote:
> > 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
> > $
> 
> I'm obviously not Corinna, but I did make a quick observation:
> 
> 195962 == 0x2FD7A
> 281474976906618 = 0x100000002FD7A
> 
> I don't know if that always holds, but it certainly looks promising.

It is.  Cygwin uses the FileID value.  Note that the FileID type is
ULONGLONG == 64 bit.  Stripping off the upper 32 bit, as apparently the
ifind and icat tools do, seems wrong to me.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
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

Re: NTFS inode ouput from ls -i

[Peter Rosin]

On 2012-11-22 22:08, Michael Lester wrote:
> 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
> $

I'm obviously not Corinna, but I did make a quick observation:

195962 == 0x2FD7A
281474976906618 = 0x100000002FD7A

I don't know if that always holds, but it certainly looks promising.

Cheers,
Peter


--
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

NTFS inode ouput from ls -i

[Michael Lester]

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