hmmm. you are right. this seems to be a bug in ruby - amazing that no-one
has seen it before though? it looks like this might be in rb_uint2big but i'm
kinda guessing since i can't compile on windows myself and therefore can't
look at config.h - except in cygwin, which works. anyhow - the numbers spat
out in cygwin are huge - so i'm gussing the bug is here. perhaps someone out
there with a windows compiler tool-chain could examine?
so, just to re-state the bug: File::stat(anypath).ino is always zero under the
one click installer, but not under cygwin using the default or compiling by
hand.
cheers.
-a
···
On Tue, 6 Sep 2005, William James wrote:
Mine:
build: i686-pc-mswin32
build_os: mswin32
host: i686-pc-mswin32
host_os: mswin32
target: i386-pc-mswin32
target_os: mswin32
Yours:
build: i686-pc-cygwin
build_os: cygwin
host: i686-pc-cygwin
host_os: cygwin
target: i686-pc-cygwin
target_os: cygwin
Try it without cygwin. On my system, stat.ino is always 0.
If anyone else is running plain windoze without cygwin, see if
File.stat(path).ino is always 0.
--
email :: ara [dot] t [dot] howard [at] noaa [dot] gov
phone :: 303.497.6469
Your life dwells amoung the causes of death
Like a lamp standing in a strong breeze. --Nagarjuna
===============================================================================
Ara.T.Howard wrote:
<snip>
so, just to re-state the bug: File::stat(anypath).ino is always zero under the
one click installer, but not under cygwin using the default or compiling by
hand.
Generally speaking, File.stat on Windows is not reliable. Too many of
that Stat members are either meaningless or wrong. Revamping it is on
my TODO list for the win32-file package.
Regards,
Dan
Ara.T.Howard wrote:
> Mine:
>
> build: i686-pc-mswin32
> build_os: mswin32
> host: i686-pc-mswin32
> host_os: mswin32
> target: i386-pc-mswin32
> target_os: mswin32
>
> Yours:
>
> build: i686-pc-cygwin
> build_os: cygwin
> host: i686-pc-cygwin
> host_os: cygwin
> target: i686-pc-cygwin
> target_os: cygwin
>
> Try it without cygwin. On my system, stat.ino is always 0.
>
> If anyone else is running plain windoze without cygwin, see if
> File.stat(path).ino is always 0.
hmmm. you are right. this seems to be a bug in ruby - amazing that no-one
has seen it before though? it looks like this might be in rb_uint2big but i'm
kinda guessing since i can't compile on windows myself and therefore can't
look at config.h - except in cygwin, which works. anyhow - the numbers spat
out in cygwin are huge - so i'm gussing the bug is here. perhaps someone out
there with a windows compiler tool-chain could examine?
so, just to re-state the bug: File::stat(anypath).ino is always zero under the
one click installer, but not under cygwin using the default or compiling by
hand.
cheers.
-a
Upon further review, this is not a bug. From the MSDN documentation on
the st_ino struct member:
"The inode, and therefore st_ino, has no meaning in the FAT, HPFS, or
NTFS file systems."
See
for more details.
Regards,
Dan
···
On Tue, 6 Sep 2005, William James wrote:
thanks daniel, some searching lead me to suspect this. seems like a severe
limitation since 'ino' is the only way to determine if a file is unique -
bummer. reading over the source leads me to think that the issue is simply a
casting bug - but that the information should be there for ruby (in the
inode). does this sound correct?
cheers.
-a
···
On Tue, 6 Sep 2005, Daniel Berger wrote:
Ara.T.Howard wrote:
<snip>
so, just to re-state the bug: File::stat(anypath).ino is always zero under the
one click installer, but not under cygwin using the default or compiling by
hand.
Generally speaking, File.stat on Windows is not reliable. Too many of that
Stat members are either meaningless or wrong. Revamping it is on my TODO
list for the win32-file package.
--
email :: ara [dot] t [dot] howard [at] noaa [dot] gov
phone :: 303.497.6469
Your life dwells amoung the causes of death
Like a lamp standing in a strong breeze. --Nagarjuna
===============================================================================
thanks for that! any idea how to tell if a file is unique on that file system
then? eg, given a filename and it's stat - how can you show that it is not
some other file? nothing but File::expand_path(pathname)?
cheers.
-a
···
On Fri, 23 Sep 2005, Daniel Berger wrote:
Upon further review, this is not a bug. From the MSDN documentation on the
st_ino struct member:
"The inode, and therefore st_ino, has no meaning in the FAT, HPFS, or NTFS
file systems."
See
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_crt__stat.2c_._wstat.2c_._stati64.2c_._wstati64.asp
for more details.
--
email :: ara [dot] t [dot] howard [at] noaa [dot] gov
phone :: 303.497.6469
Your life dwells amoung the causes of death
Like a lamp standing in a strong breeze. --Nagarjuna
===============================================================================
Hi,
At Fri, 23 Sep 2005 07:01:39 +0900,
Ara.T.Howard wrote in [ruby-talk:157179]:
thanks for that! any idea how to tell if a file is unique on that file system
then? eg, given a filename and it's stat - how can you show that it is not
some other file? nothing but File::expand_path(pathname)?
eban has suggested File.identical? for that purpose.
···
--
Nobu Nakada
that sounds great - but how would it be implemented on windows if there is no
unique field in the inode?
-a
···
On Fri, 23 Sep 2005 nobu.nokada@softhome.net wrote:
eban has suggested File.identical? for that purpose.
--
email :: ara [dot] t [dot] howard [at] noaa [dot] gov
phone :: 303.497.6469
Your life dwells amoung the causes of death
Like a lamp standing in a strong breeze. --Nagarjuna
===============================================================================
Hi,
At Fri, 23 Sep 2005 08:49:15 +0900,
Ara.T.Howard wrote in [ruby-talk:157186]:
> eban has suggested File.identical? for that purpose.
that sounds great - but how would it be implemented on windows if there is no
unique field in the inode?
Of course, comparing expanded pathes 
···
--
Nobu Nakada
lol!
that's fine - but does that work with hard/soft links? i know next to nothing
about windows but remember something about it having something like hard links
and:
harp:~ > touch a
harp:~ > ln a b
harp:~ > ruby -e'p File::expand_path("b")'
"/home/ahoward/b"
so that's wouldn't work on unix - maybe it does on windows?
-a
···
On Fri, 23 Sep 2005 nobu.nokada@softhome.net wrote:
Hi,
At Fri, 23 Sep 2005 08:49:15 +0900,
Ara.T.Howard wrote in [ruby-talk:157186]:
eban has suggested File.identical? for that purpose.
that sounds great - but how would it be implemented on windows if there is no
unique field in the inode?
Of course, comparing expanded pathes
--
email :: ara [dot] t [dot] howard [at] noaa [dot] gov
phone :: 303.497.6469
Your life dwells amoung the causes of death
Like a lamp standing in a strong breeze. --Nagarjuna
===============================================================================
1. There is, at least on NTFS, a unique file identifier that is
somehow available. Don't ask me how right now, but I should be able to
find out in a few days (work-related stuff).
2. Files cannot be hardlinked on any Windows filesystem. Directories
can be hardlinked on NTFS5 systems.
-austin
···
On 9/22/05, nobu.nokada@softhome.net <nobu.nokada@softhome.net> wrote:
> > eban has suggested File.identical? for that purpose.
> that sounds great - but how would it be implemented on windows if there is no
> unique field in the inode?
Of course, comparing expanded pathes
--
Austin Ziegler * halostatue@gmail.com
* Alternate: austin@halostatue.ca
1. There is, at least on NTFS, a unique file identifier that is
somehow available. Don't ask me how right now, but I should be able to
find out in a few days (work-related stuff).
The file's unique ID is assigned by the system and is stored in the
nFileIndexHigh and nFileIndexLow fields of BY_HANDLE_FILE_INFORMATION
(API call
is GetFileInformationByHandle())
(source: MSDN)
2. Files cannot be hardlinked on any Windows filesystem. Directories
can be hardlinked on NTFS5 systems.
Erm.. they can - use CreateHardLink() - but there is no shell support for them
(so that users won't delete real files by accident I guess).
Directories ~cannot~ be hard-linked (but apparently you can create
'junction points' - a
kind of soft link - though I've never used them myself).
Regards,
Sean
···
On 9/23/05, Austin Ziegler <halostatue@gmail.com> wrote:
Hi,
At Fri, 23 Sep 2005 11:16:48 +0900,
Sean O'Halpin wrote in [ruby-talk:157221]:
> 1. There is, at least on NTFS, a unique file identifier that is
> somehow available. Don't ask me how right now, but I should be able to
> find out in a few days (work-related stuff).
The file's unique ID is assigned by the system and is stored in the
nFileIndexHigh and nFileIndexLow fields of BY_HANDLE_FILE_INFORMATION
(API call
is GetFileInformationByHandle())
(source: MSDN)
Thank you for the info. I've forgotton it. It will be used in
the case it is available.
> 2. Files cannot be hardlinked on any Windows filesystem. Directories
> can be hardlinked on NTFS5 systems.
>
Erm.. they can - use CreateHardLink() - but there is no shell support for them
(so that users won't delete real files by accident I guess).
Mswin32 and mingw32 version rubys support it.
Directories ~cannot~ be hard-linked (but apparently you can create
'junction points' - a
kind of soft link - though I've never used them myself).
Right. It wouldn't be identical to the original.
···
--
Nobu Nakada