Message-Id: <6.2.5.6.2.20120511153828.05cd2140@binnacle.cx>
Date: Fri, 11 May 2012 15:42:33 -0400
To: cygwin AT cygwin DOT com, jra AT samba DOT org
From: starlight DOT 2012q2 AT binnacle DOT cx
Subject: Re: CYGWIN inode over Samba share not constructed from    IndexNumber
In-Reply-To: <20120511175843.GL13090@calimero.vinschen.de>
References: <6 DOT 2 DOT 5 DOT 6 DOT 2 DOT 20120511125624 DOT 05cd1ff8 AT binnacle DOT cx> <20120511175843 DOT GL13090 AT calimero DOT vinschen DOT de>
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
Precedence: bulk
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

At 07:58 PM 5/11/2012 +0200, Corinna Vinschen wrote:
>Which Samba version introduced this behaviour?

Don't know.

I'm stepping aside on this now.  Just
reported it since it came up and broke
a script we have.  I've worked around
the inode test by comparing 'sha1sum'
values for the files and re-hard-linking
the files when the sums differ.

I understand this stuff can be tricky,
but if it's at all possible it seems
reasonable to ask that the behavior of
CYGWIN+Samba parallel Linux native
behavior w/r/t apparent inode values being
the same when actual inode values match.

I like the idea that the true inode
values be represented by CYGWIN+Samba
whenever possible.


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