X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:reply-to:to:subject:from:message-id:date
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	default; b=Ji1uaVpwOxPRHrEXrXI6tyk9QdHBMugft9ZWTWMUZXePJWucPr+AX
	twknFEO1VFhN5OkXlpat71LWSIgHhnKhmh49I8jzrMfRubfBxsTRIyahpaCkFFZ9
	bl/gX+Fj7nrZTbgDJxEYjYvapUqf8TJFlP//mfpOMGtHJsP1zOP1TY=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:reply-to:to:subject:from:message-id:date
	:mime-version:content-type:content-transfer-encoding; s=default;
	bh=8W2YB4mlT1oGRuCY8aF7VtY7OOo=; b=lPJhtQFR3Prl8YVEZ/mJQ8arCUaT
	TgjoQJ+xQhYWXDAcopajbVwN3sfWw++o2XuBfuXZZFAcmdpG4Opdv9nBJq4U1wAR
	iFF306u3XVeMmHxPDYzLwuLY1+gbiY8WO1siWJt8DgQViXc0HY2sxi+Io5bcVpWP
	NmfjslUKcOAMxRY=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.2 spammy=HX-HELO:sk:p3plsmt, Hx-spam-relays-external:sk:p3plsmt, H*RU:sk:p3plsmt
X-HELO:	p3plsmtpa06-09.prod.phx3.secureserver.net
Reply-To:	w5pny AT w5pny DOT com
To:	cygwin AT cygwin DOT com
Subject:	Re: NTFS inode ouput from ls -i
From:	Harry G McGavran Jr <w5pny AT w5pny DOT com>
Message-ID:	<fddebd26-d2fa-1581-4c34-ae79e9d21009@w5pny.com>
Date:	Tue, 18 Jul 2017 16:10:26 -0600
User-Agent:	Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version:	1.0
X-CMAE-Envelope:	MS4wfMZl23BQMhzyLzFXcUI3LrmHv3rpoVnkldiu0ijCekv+qpS7AfAt3i+L+xWaKl8/h5UkLnDW6DXqYWN9hcyMTJUFC+tBZLX1fmX2PKLPT515OwuKd1cZ 8mYK08eIVj6KCImoLAlcvZWvNg8e/ROqlamCJUQFfE+8lq2a2HzUw+IZ

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

- Raw text -