From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16677 invoked by alias); 18 Jul 2017 09:50:17 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 16669 invoked by uid 89); 18 Jul 2017 09:50:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-99.4 required=5.0 tests=AWL,BAYES_50,GOOD_FROM_CORINNA_CYGWIN,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Kit, summarized, Harry, ntfs X-HELO: drew.franken.de Received: from mail-n.franken.de (HELO drew.franken.de) (193.175.24.27) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 18 Jul 2017 09:50:14 +0000 Received: from aqua.hirmke.de (aquarius.franken.de [193.175.24.89]) (Authenticated sender: aquarius) by mail-n.franken.de (Postfix) with ESMTPSA id 21283721E280C for ; Tue, 18 Jul 2017 11:50:10 +0200 (CEST) Received: from calimero.vinschen.de (calimero.vinschen.de [192.168.129.6]) by aqua.hirmke.de (Postfix) with ESMTP id 2451A5E03CB for ; Tue, 18 Jul 2017 11:50:09 +0200 (CEST) Received: by calimero.vinschen.de (Postfix, from userid 500) id 062F1A8063E; Tue, 18 Jul 2017 11:50:09 +0200 (CEST) Date: Tue, 18 Jul 2017 15:49:00 -0000 From: Corinna Vinschen To: cygwin@cygwin.com Subject: Re: NTFS inode ouput from ls -i Message-ID: <20170718095009.GB26902@calimero.vinschen.de> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: <77d1bb70-5bce-0ac0-e011-1997f7db8a25@w5pny.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) X-SW-Source: 2017-07/txt/msg00265.txt.bz2 --k1lZvvs/B4yU6o8G Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 1961 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" Content-length: 819 -----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--