Re: [jgit-dev] isOutdated() and lastModified()

[Dmitry Pavlenko <dmit10@xxxxxxx>]

Thank you for explanation. But I wonder if there's a method that says 
Repository that config/a certain ref or all refs/index  is invalid and should 
be updated if needed? If there's no such method it would be highly useful for 
those who uses jgit as a library works with config/refs/index not only through 
jgit calls but using some other quick methods (like git cli or FileWriter).

On Sunday 12 December 2010 14:17:44 you wrote:
> 12 dec 2010 kl. 04:50 skrev Shawn Pearce:
> > On Sat, Dec 11, 2010 at 8:23 AM, Robin Rosenberg
> > 
> > <robin.rosenberg@xxxxxxxxxx> wrote:
> >> 11 dec 2010 kl. 17:02 skrev Dmitry Pavlenko:
> >>> I seems that FileBasedConfig (and loose-refs-related classes) relies on
> >>> java.io.File.lastModified() call (at least in isOutdated() method).
> >>> 
> >>> For my Sun Java 1.6.0.22 and OpenJDK 1.6.0 (Debian squeeze/sid)
> >>> java.io.File.lastModified() can be the same after changes in the file.
> >>> 
> >>> I don't know is it expected, is it JDK bug, or JGit problem. Do you?
> >> 
> >> This is expected. If the changes are quick enough, the clock will not
> >> step forward in between.
> > 
> > ...
> > 
> >> There is a workaround for this in JGit and the original C Git, aka "racy
> >> git", which means that we sometimes need to read the file to check if
> >> it has changed.
> > 
> > I wonder if we can't use DirCache to help us with the config and
> > packed-refs files, and their "racy git" update problems.  If we create
> > $GIT_DIR/config.index as a standard DirCache format with only two
> > files in it (config and packed-refs), we can use the cached stat
> > information in that file to tell us if config or packed-refs is racily
> > clean.  If it is, we can read the files again.  We might even be able
> > to use it for the loose ref files, to try and catch them being racily
> > clean too.
> 
> We cache a timestamp internally. We could add one to notice the last
> time we checked, or use the current one (last modified) differently, so I
> do not think we need a new file for that. Command line JGit will need to
> read the refs anyway. But I think you are right that we should modify this.
> I did not read Dmitry's message close enough.
> 
> > Another idea is to use what you suggested before somewhere else (I'm
> > sorry I can't recall where this is)... if the file modification time
> > is less than 3 seconds different from the last time we read the file,
> > consider it outdated and read the file again anyway.
> 
> That was a different story. The idea was to avoid a stat call to check the
> length of a file against the cached information in the index, but assuming
> that a if the length changed, then the timestamp would too. The three
> seconds come from the file system with the lowest timestamp resolution of
> two seconds. For refs we don't check the length at all, so there is no
> extra stat to avoid.
> 
> -- robin