On Sun, 2009-11-08 at 03:46 +0000, John A Meinel wrote:
>
>
> In running the test suite, I found that
>
> os.lstat('file')
> versus
> os.fstat(open('file', 'rb').fileno())
>
> gives slightly different results.
>
> Namely, the latter will have a value for 'st.st_ino' while the former
> will have 0 stored.
>
> I haven't investigated, but potentially this is a performance issue
> for
> Windows and dirstate. If dirstate ends up caching the result of
> fstat()
> but then when iterating we compare that to lstat() we will think the
> content has changed, and re-read and re-sha the file. If we then
> stored
> the value from fstat() again, we would have done all that work and
> then
> store bogus data again.
>
> I don't think we are being that bad, or we would have noticed earlier.
> But it is something we should be careful about trusting fstat versus
> lstat, and I haven't had a chance to audit the code.
On Sun, 2009-11-08 at 03:46 +0000, John A Meinel wrote: open('file' , 'rb').fileno())
>
>
> In running the test suite, I found that
>
> os.lstat('file')
> versus
> os.fstat(
>
> gives slightly different results.
>
> Namely, the latter will have a value for 'st.st_ino' while the former
> will have 0 stored.
>
> I haven't investigated, but potentially this is a performance issue
> for
> Windows and dirstate. If dirstate ends up caching the result of
> fstat()
> but then when iterating we compare that to lstat() we will think the
> content has changed, and re-read and re-sha the file. If we then
> stored
> the value from fstat() again, we would have done all that work and
> then
> store bogus data again.
>
> I don't think we are being that bad, or we would have noticed earlier.
> But it is something we should be careful about trusting fstat versus
> lstat, and I haven't had a chance to audit the code.
Cygwin or win32?
-Rob