On Fri, Dec 12, 2014 at 3:41 AM, Torsten Bögershausen <tbo...@web.de> wrote: > Even if I share the the concerns that the cache may work on one system, > but not on the other, there should be better ways to protect from that. > > Using the uname does not really help, if you move one repo from NTFS to VFAT, > we will not detect it (assuming we use Windows). > (And how much do we need to support the move of a repo ?) > > There is a concern that this may not work, when different clients are > accessing > the repo, using the UNTR extension. > > Some kind of sanity check would be good to have, what can be done ? > The most important things are the timestamps. > I can think of 2 sanity checks: > - If the modified time stamp of a directory is older then the create time of > any file, > the UNTR cache can not be used. > - If the timestamp of a file changes, but the sha1 sum is the same, what does > this mean? > The file (or the whole repo) has been copied, or the time stamping does not > work. > > A simple verification of the FS could be to stat() .git/, create a temp file, > delete it and > stat() again. If mtime does not change, the FS is unusable for UNTR.
This is a slow test. Some filesytem only supports second resolution timestamps. If you create and delete the file so fast, mtime may remain in the same second even if the fs is supported. We need to wait a second between those operations (this is why "update-index --untracked-cache" takes several seconds). So it cannot be done often (i.e. at startup of every command) > Then we could extend the uname idea: > Create a string in UNTR which is a collection of lines like this: > > Working-For: Linux;/mnt/nfs/projects/project1 > Not-OK-For: WIndows:/a:/project1 > (Of course the strings can be made nicer, and '\n' is URL-encoded.) > > Each system that is not listed needs to probe the repo, add another line > and re-write the index. > > We can even add a "best-for" line, and invalidate the UNTR every 12 hours or > so. It starts to look complicated. How about letting the user deal with it? UNTR will support storing multiple "location" lines. Whenever UNTR is needed at a new location, it's disabled. The user has to use 'update-index' to test the new location and add it to UNTR. The user can choose to keep current locations (network access), or replace them all with the new one (repo move), or just mark the new location unusable so the extension is kept for use in other places, but warning at this place is suppressed. THe "localtion" consists of worktree path, system name and host name. > Should we think about having an ASCII area for additional information, which > is part > of the stone, but the content is flexible ? These lines are already in free form. If the running system generates the same string as stored in UNTR, it's allowed to use the extension. We need code to understand this content, so flexibility must be within limit.. -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
