When using z as a git submodule, the .z.* cache files cause the submodule be considered "dirty", which is annoying. Using .gitignore on the .z.* files fixes the issue.
add gitignore for .z.* files for clean submodule
I'm concerned about this ... .z.something files are an indication that something isn't working correctly. They are tmp files that were supposed to be mv'd to .z.
Usually these get pooped out if there is a directory at $HOME/.z but there is also some sort of race condition that some users experience where these files occasionally get dropped in $HOME ... which I have not been able to get to the bottom of.
I'm also seeing a few "$HOME/.z." files as well last modified last week. My "$HOME/.z" file is still being though; its mtime changes when I cd around. The ".z." files in the submodule have now disappeared. How long are they supposed to persist as tmp files?
They aren't supposed to persist at all. In order to prevent race condition wiping the ~/.z file, we write to a tmp file ~/.z.XXXXX and then mv the temp file to ~/.z, (mv is atomic). So every one of those files represents a single 'miss'.
I think what's going on at this point is that, the file is written everytime a $PS1 is displayed, and that's not the fastest operation, so occasionally the mv fails cause the OS has a lock on ~/.z. Unfortunately, this is hard to test. I proposed:
- env mv -f "$tempfile" "$datafile"
+ env mv -f "$tempfile" "$datafile" || env rm -f "$tmpfile"
but have received anecdotal evidence that this doesn't solve the problem for some people. Tempted to push it anyway.
In fact, I have pushed that.
#146 is tracking the underlying issue with this