Duplicate inodes from file stat on windows

On Jul 10, 12:18 pm, "neuronst...@xxxxxxxxx" <neuronst...@xxxxxxxxx>
On Jul 10, 11:49 am, Uwe Klein <uwe_klein_habertw...@xxxxxxxxxxx>

Uwe Klein wrote:
neuronst...@xxxxxxxxx wrote:

The inode values are quite large, so I'm wondering if Tcl is not
handling them properly.
e.g according to cygwin's ls -i the
inodes are 412318698004 & 412318698036
Tcl's file stat shows both with 'ino' field = 2676

% format %016lx\n%016lx\n%016lx\n 412318698004 412318698036 2676

no direct idea


This any further help?:

uwe- Hide quoted text -

- Show quoted text -

Well, in this case cygwin's ls is just a tool I'm using to verify
outside of Tcl that the inodes are different.. so cygwin isn't in the
code-path of the problem.

There are no hard links involved.. so thanks.. but it doesn't really
shed any light on it for me.

Julian- Hide quoted text -

- Show quoted text -

Looking at the generic/tclFCmd.c CopyRenameOneFile function,
It seems to short circuit with a TCL_OK result if the inode and device
numbers of source & destination match,
so it looks like it's the duplicate inodes that are the cause of the
file rename misbehaviour.

The fact that I encountered it on a folder from a samba share on a
remote filesystem seems to be a red herring.

I did a scan on my c: drive , recursively scanning the folders and
storing inodes as reported by file stat as the key of an array.
Tcl's file stat on my vista machine is reporting the same inode for a
huge number of files.

This would seem to make the process of using Tcl's file rename to
rename a new version of a file into place a very risky proposition on