|Re: [jgit-dev] isOutdated() and lastModified()|
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 22.214.171.124 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. 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. -- Shawn.
Back to the top