Christian Couder <christian.couder@xxxxxxxxx> writes: >> You are listing only the irrelevant cases. The shared one may be >> used immediately, and the user can keep using it for a while without >> "touching". > > Now you are talking about a case where the shared index file can be > used immediately and the user can keep using it. > This is a different case than the case I was talking about (which is > the case when the shared index file does not exist anymore). Yes, as I said, you are listing irrelevant and uninteresting one. If the shared index is already gone, reporting failure to touch it is of no use---an attempt to read and use the split index that depends on the shared index that is gone will fail anyway. > In a previous email you wrote that if the file system is read only, it > is a bad thing if we warn. Yes, but you need to realize that "it is better not to bother users with a report of failure to touch in read-only repository" and "we ignore all failures". IIUC, you attempt to touch the shared index even when you are only reading the index, because you want to mark the fact that the shared index is still being depended upon. And I tend to agree that it is OK not to report a failure for that case. It is very similar to a situation where you are asked to peek into your coworker's repository, which you do not have write access to, and run "status". The command first runs the equivalent of "update-index --refresh" only in-core, and it attempts to write the updated index because (1) it paid the cost of doing the refreshing already, and (2) if it can write into the index, it will help future operations in the repository. But it does not report a failure to write the index exactly because it is merely doing an opportunistic write. And in the "we read from the split index, and we attempt to touch the underlying shared one to update its timestamp" case, it is OK not to report if we failed to touch. But you also attempt to touch the shared index when you are actually writing out a new split index file based on it, no? The "you created a ticking bomb" situation is where you fail to touch the shared index for whatever reason, even when you managed to write the new split index file. We agreed that read-only operation should not nag, so it won't trigger when you are peeking somebody else's repository to help him. As I said, it is an uninteresting and irrelevant case---when your read-only peeking did not add new information to be preserved, it is less severe problem that you fail to reset the expiration. On the other hand, if you added new information, i.e. wrote the split index based on it, it is a good indication that the <split,shared> index pair has information that is more valuable. We must warn in that case. > Now if you want to talk about the case when the shared index file has > not been removed, but just chowned to "root", then I wonder how is it > different from the case when the file system is read only. The difference is that your code has enough information to notice the case where you know your touch failed, you know that you wanted to write (and the write succeeded), and yet you do NOT know why your touch failed. That is the ticking bomb we need to warn the user about.