RFC: win32 fstat inconsistencies

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

So it seems Windows does something weird wrt stat returns. Specifically,
os.lstat gives different results from os.fstat:

  f = open('bzr', 'rb')
  fst = os.fstat(f.fileno())
  lst = os.lstat('bzr')
  lst != fst

The big difference that I can see is that os.fstat() has a value in
"st.st_ino", while os.lstat() returns 0 for st_ino.

I was trying to decide what to do with that. At the moment it is causing
the test suite to fail in
"workingtree_implementations.get_file_with_stat". My first feeling was
to change the assertEqualStat() function, to skip the st_ino field for
windows, but I realized that this might actually be effecting the
performance of dirstate-after-commit. Namely, we use st_ino in the
hash-cache to detect if a file has been changed. When we stat the file,
it will be giving us a different result than the one we would have
gotten from os.fstat() during commit.

I don't have a great answer yet. My first thought about fixing it was to
have WT.get_file_with_stat() set the st_ino back to 0 on win32, since we
know that it won't match the future lstat() call. However, these objects
are an "nt_stat" result builtin object. Which means that you cannot
mutate them. And it doesn't seem quite right to wrap them in yet-another
class...

So I could:

1) Create a dummy stat result to wrap the os.fstat() return which always
returns 0 for st_ino.
2) Change the assertEqualStat() function to allow the st_ino to differ,
and then change the dirstate code to always ignore the st_ino field on
windows.

Thoughts?

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkm5iv8ACgkQJdeBCYSNAAPTWwCgnyg07AbzdckYGhMHuhLviiwX
rl0An0YRXdO+MBQLFl3phN/dgCm/Pa2C
=K3Cf
-----END PGP SIGNATURE-----