This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: ld/emultempl/elf32.em trusts inode numbers even under Mingwin
- From: Zack Weinberg <zack at codesourcery dot com>
- To: "Dave Korn" <dave dot korn at artimi dot com>
- Cc: "'Binutils Mailing List'" <binutils at sources dot redhat dot com>
- Date: Thu, 03 Feb 2005 10:01:56 -0800
- Subject: Re: ld/emultempl/elf32.em trusts inode numbers even under Mingwin
- References: <NUTMEGw2hneZ5NhI4FX0000050d@NUTMEG.CAM.ARTIMI.COM><87d5vhh771.fsf@codesourcery.com>
Zack Weinberg <zack@codesourcery.com> writes:
> "Dave Korn" <dave.korn@artimi.com> writes:
>> I must throw in an AYS? here.... AFAIK, cygwin generates pseudo
>> inode-nums by hashing the filename. This behaviour is inconsistent
>> across different windows versions (NT vs 9x series), different
>> filesystems (FAT vs NTFS particularly), and
>> local-vs-remote-SMB-mounted drives. In a quick test, I couldn't
>> even get that result when using the -mno-cygwin flag to build a
>> mingw-targeted rather than cygwin-targeted; the inode was zero, but
>> the device field wasn't.
>
> All I can say is that I observe all four values as zero in my
> relatively limited testing. I build my Windows-hosted toolchains
> with cross compilers from i686-linux to i686-mingw32, though.
>
> Rereading, I see I got the test wrong - it was meant to be
> (st.st_dev != 0 || st.st_ino != 0). I'm not quite sure I understand
> what you are saying; does that correction address your concern?
It's been pointed out to me that MSVCRT's documentation claims to
provide meaningful st_dev (it corresponds to the drive letter). I
don't know why I was getting zeroes then. Anyway, at this point I
throw up my hands and plead for help from someone who knows more about
Windows. (Maybe we should #if that block out if (_WIN32 &&
!__CYGWIN__) rather than being clever?)
zw