NTFS inode ouput from ls -i
Tue Jul 18 15:49:00 GMT 2017
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:
> 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 Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: not available
More information about the Cygwin