This is the mail archive of the
mailing list for the Cygwin project.
Re: NTFS inode ouput from ls -i
- From: Harry G McGavran Jr <w5pny at w5pny dot com>
- To: cygwin at cygwin dot com
- Date: Tue, 18 Jul 2017 16:10:26 -0600
- Subject: Re: NTFS inode ouput from ls -i
- Authentication-results: sourceware.org; auth=none
- Reply-to: w5pny at w5pny dot com
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.
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.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple