Re: ld/emultempl/elf32.em trusts inode numbers even under Mingwin

[Zack Weinberg <zack at codesourcery dot 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