DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=RHyPRNeMovGecYyoaRnIjGvWfpLSPmfHVHlK1Yb4IcrnJptQcd2HB
	SWTDUfMqTPb3BzLL3rzvot5Na3EcbkNf8Eq4UHuew0m2RgHWQLBPMYvLGR+/J64L
	rFMbF04mw1uYX5coy2KZrWUhbibz1xgsgSPX8S/JwN6UAZ2HWkHdeY=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Date: Tue, 18 Jul 2017 11:50:09 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: NTFS inode ouput from ls -i
Message-ID: <20170718095009.GB26902@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <77d1bb70-5bce-0ac0-e011-1997f7db8a25 AT w5pny DOT com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;	protocol="application/pgp-signature"; boundary="k1lZvvs/B4yU6o8G"
Content-Disposition: inline
In-Reply-To: <77d1bb70-5bce-0ac0-e011-1997f7db8a25@w5pny.com>
User-Agent: Mutt/1.8.3 (2017-05-23)

--k1lZvvs/B4yU6o8G
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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:
>=20
> https://cygwin.com/ml/cygwin/2012-11/msg00172.html
>=20
> 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.
>=20
> 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-k=
it-pt-3.html

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

--k1lZvvs/B4yU6o8G
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJZbdnQAAoJEPU2Bp2uRE+gD9UP/0FCIAog8USfZhLCWeF9YjiX
0uYM3p6PT+qqQFhmREiagQ3ya+9TxRMDrSP+3b76NRtnPXnyB9L07EzR5SBEKiUt
+HLj66wJODJuyd27whVR97vlIMUBj4doJYlioeRZvCyNKsgN7p+4PtUoRCWiWyDk
/7f7RxOKeKlGPDNkOSLYIpYJl2cQ+0hcLUFxVMBc1JzaiPhlIgRgIXwuCOO4FvYh
jNOKp91hfjw7ylSKueftN8MZFF3oVyPqMdNfw/fEzsl9QAkza/fjXFwR8ThzWRnH
CFG1qxeBolbrmHV2uMzT2enbxJXmDYm+WoIPX7WK+/3KfE3qP74ULfdQ8RG1FhPc
VDFAcHqMyWQOIeaLADFnz3nt2o6XH5Rjrdlk1k2CkHDHLwGCUPy1rfT9LCR4Ut84
l6T1kGZnEZoEgzYV84tsrGlmPREBM+KhUrRGbCS5eE9A6z3ilGQ1b6ZSuCzInvOz
J0XTpbbanSWsDubni1MSkHLoxiqp0BE1aVR4fpPyKxyw8w4NAV7hjXks+PSkbbr2
Ty8ovzf2YElj2Gu6WGKJBmpBbgK38M8Lkl42EEoslNNTXBcSHWgKUY8N5RBf9jJv
t1ZrXuNIxUGUIz3zMwmYohCl57RNwqCRnEH7inixaYpClbLwsXlJijj8OSuKuOF0
kG6tN4i9HXxgoeqnGFtQ
=Sla0
-----END PGP SIGNATURE-----

--k1lZvvs/B4yU6o8G--