Message-Id: <6.2.5.6.2.20120511114149.05c9f560@flumedata.com>
Date: Fri, 11 May 2012 11:42:44 -0400
To: cygwin AT cygwin DOT com
From: starlight DOT 2012q2 AT binnacle DOT cx
Subject: CYGWIN inode over Samba share not constructed from  IndexNumber
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Received-SPF: pass (mx.binnacle.cx: 172.29.87.10 is whitelisted by SPF-milter whitelist entry)
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

Hello,

Ran into a quirk that caused some trouble.

For some reason CYGWIN 1.7.5 (I know this is old)
is constructing inode values for files on
Samba (3.6.4) shares with a different algorithm
than is used for files on NTFS volumes.

This caused a script that checks for matching
hard-links to fail.

Confirmed that Samba is returning the actual
inode values in 'IndexNumber' with 'procmon'
while running the

   stat -c '%h %d %i' filename

command.  See https://lists.samba.org/archive/samba/2012-May/167381.html.

Is CYGWIN mistaking the Samba share for a FAT32
volume and using an inode-faking algo?  Or
is it something else?  Was this fixed in
a newer version of CYGWIN?  I did try a search
but came up with nothing.  With NTFS the
inode values reported do match the underlying
'IndexNumber' value.

Please CC me with any replies as I am not
subscribed to the list.

Thanks


--
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