Duplicate inodes from file stat on windows
in [TCL]
|
Prev: Tcl-URL! - weekly Tcl news and links (Jul 10)
Next: Warning/Heads up: Tk and Future X.org Incompatibility
From: neuronstorm on 10 Jul 2008 12:45 On Jul 10, 12:18 pm, "neuronst...(a)gmail.com" <neuronst...(a)gmail.com> wrote: > On Jul 10, 11:49 am, Uwe Klein <uwe_klein_habertw...(a)t-online.de> > wrote: > > > > > > > Uwe Klein wrote: > > > neuronst...(a)gmail.com 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 > > > 00000060001c0a14 > > > 00000060001c0a34 > > > 0000000000000a74 > > > > no direct idea > > > > uwe > > > This any further help?: > > http://cygwin.com/ml/cygwin/2005-11/msg00811.html > > > 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 windows. Julian
From: neuronstorm on 10 Jul 2008 13:04 On Jul 10, 4:45 pm, "neuronst...(a)gmail.com" <neuronst...(a)gmail.com> wrote: > On Jul 10, 12:18 pm, "neuronst...(a)gmail.com" <neuronst...(a)gmail.com> > wrote: > > > > > > > On Jul 10, 11:49 am, Uwe Klein <uwe_klein_habertw...(a)t-online.de> > > wrote: > > > > Uwe Klein wrote: > > > > neuronst...(a)gmail.com 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 > > > > 00000060001c0a14 > > > > 00000060001c0a34 > > > > 0000000000000a74 > > > > > no direct idea > > > > > uwe > > > > This any further help?: > > > http://cygwin.com/ml/cygwin/2005-11/msg00811.html > > > > 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 > windows. > > Julian- Hide quoted text - > > - Show quoted text - To give an idea of the magnitude of inode sharing.. Out of over 810K files on my c: drive there were over 53K duplicated inodes.. with 742K files sharing them. Largest number of files mapping to a single inode: 84 Julian
From: Uwe Klein on 10 Jul 2008 14:19 neuronstorm(a)gmail.com wrote: > > To give an idea of the magnitude of inode sharing.. > Out of over 810K files on my c: drive > there were over 53K duplicated inodes.. with 742K files sharing them. > Largest number of files mapping to a single inode: 84 54k? thats nearly 64k / 16bit Could it be that inode number were some 16 bit value in some version long past? uwe
From: neuronstorm on 10 Jul 2008 15:02
On Jul 10, 6:19 pm, Uwe Klein <uwe_klein_habertw...(a)t-online.de> wrote: > neuronst...(a)gmail.com wrote: > > > To give an idea of the magnitude of inode sharing.. > > Out of over 810K files on my c: drive > > there were over 53K duplicated inodes.. with 742K files sharing them. > > Largest number of files mapping to a single inode: 84 > > 54k? thats nearly 64k / 16bit > > Could it be that inode number were some 16 bit value in some > version long past? > > uwe You're right! I just checked and the number of inodes used by my files was 65536 Julian |