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: List-Subscribe: List-Archive: List-Post: List-Help: , 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 Message-ID: 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 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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