add gitignore for .z.* files for clean submodule #93

Closed
wants to merge 1 commit into from

2 participants

@adjohnson916

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.

@rupa
Owner

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.

@adjohnson916

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?

@rupa
Owner

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.

@rupa
Owner

In fact, I have pushed that.

@rupa
Owner

#146 is tracking the underlying issue with this

@rupa rupa closed this Feb 14, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment