Theodore Ts'o <ty...@mit.edu> writes: > The main issue is that non-expert users might not realize that they > really need to run "git fsck" after a crash; otherwise, what might > happen is that although git is only appending, that you might have > some zero-length (or partially written) git object or pack files, and > while you might not notice at that moment, it might come and bite you > later.
Regarding loose object files, given that we write to a temporary, optionally fsync, close and then move to the final name, would we still see partially written file if we omit the fsync, or would the corruption be limited to either empty or missing? The reason I am wondering is because the codepath to create an object (i.e. "update-index --add", "hash-object -w", or "add") first checks if a packed or a loose object file _exists_ and if so bypasses writing the same thing anew, but the existence check for a loose object is to merely making sure that access(F_OK) (and optionally utime()) succeeds. If the potential breakage is limited to truncation to empty, then we could replace it with stat(2) and st.st_size check, as no loose object file can be empty. -- 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
