Re: git bugs

"Ben Lynn" [off-list ref] writes:

... I'm making the same
assumptions, i.e. files are not touched while they're being indexed.

Actually you are making another assumption that is somewhat worrysome.

The filesystem clock and time(2) clock can be skewed and comparing a
timestamp you obtain from lstat(2) and time(2) might not give you any
meaningful information.  That is why I made this codepath without using
time(2) when I did the racy-git work.

That is problematic. How do I figure out what the filesystem thinks is
the current time? I could touch some file and read its mtime, but I
want a shortcut.

Are there any guarantees of any kind? e.g. is the filesystem current
time at least never ahead of the system time?

-Ben

On Tue, Jun 10, 2008 at 5:20 PM, Junio C Hamano [off-list ref] wrote:

"Ben Lynn" [off-list ref] writes:

quoted

... I'm making the same
assumptions, i.e. files are not touched while they're being indexed.

Actually you are making another assumption that is somewhat worrysome.

The filesystem clock and time(2) clock can be skewed and comparing a
timestamp you obtain from lstat(2) and time(2) might not give you any
meaningful information.  That is why I made this codepath without using
time(2) when I did the racy-git work.

Also, without using the time(2) call, how would we write the timestamp
of the index to the file as Linus suggests? I'm guessing we'd write
it, then read its mtime, and the write it again (just the part storing
the timestamp), but that seems inelegant. In addition, the second
write may happen in the next second and you'll get an mtime different
to that in the file, though that shouldn't matter.

-Ben

On Tue, Jun 10, 2008 at 5:24 PM, Ben Lynn [off-list ref] wrote:

That is problematic. How do I figure out what the filesystem thinks is
the current time? I could touch some file and read its mtime, but I
want a shortcut.

Are there any guarantees of any kind? e.g. is the filesystem current
time at least never ahead of the system time?

-Ben

On Tue, Jun 10, 2008 at 5:20 PM, Junio C Hamano [off-list ref] wrote:

quoted

"Ben Lynn" [off-list ref] writes:

quoted

... I'm making the same
assumptions, i.e. files are not touched while they're being indexed.

Actually you are making another assumption that is somewhat worrysome.

The filesystem clock and time(2) clock can be skewed and comparing a
timestamp you obtain from lstat(2) and time(2) might not give you any
meaningful information.  That is why I made this codepath without using
time(2) when I did the racy-git work.

Ben Lynn wrote:

That is problematic. How do I figure out what the filesystem thinks is
the current time? I could touch some file and read its mtime, but I
want a shortcut.

That basically is as short as it gets, except perhaps statting a freshly
modified file (not necessarily by oneself).

Are there any guarantees of any kind? e.g. is the filesystem current
time at least never ahead of the system time?

Practically no guarantees, just that it is rather likely for the time at
the fileserver to progress at about the same pace as yours.
-- 
Sincerely,
           Stephen R. van den Berg.

Differentiation is an integral part of calculus.

Thanks everyone who replied. You know, I was a bit apprehensive about
posting originally, because I had heard the git ML was inflammable.
But all these responses have been prompt, well-thought-out and
informative.

I plan to take all these suggestions and have a go at hacking a
race-free index which updates successfully despite concurrent file
operations.

Thanks again,
-Ben

On Wed, Jun 11, 2008 at 5:46 AM, Stephen R. van den Berg [off-list ref] wrote:

Ben Lynn wrote:

quoted

That is problematic. How do I figure out what the filesystem thinks is
the current time? I could touch some file and read its mtime, but I
want a shortcut.

That basically is as short as it gets, except perhaps statting a freshly
modified file (not necessarily by oneself).

quoted

Are there any guarantees of any kind? e.g. is the filesystem current
time at least never ahead of the system time?

Practically no guarantees, just that it is rather likely for the time at
the fileserver to progress at about the same pace as yours.
--
Sincerely,
          Stephen R. van den Berg.

Differentiation is an integral part of calculus.