Hi, I have a problem in a server repo where it seems that some previous "git push" command by some user has left a stale .keep file in the repo.git/objects/pack/ directory. Now, when trying to clone the repo on the server, the clone fails with: $ git clone --bare /path/to/repo.git myclone.git Cloning into bare repository myclone.git... fatal: failed to copy file to 'myclone.git/objects/pack/pack-6195737bf980830662f9a44eced023ca4ebe083a.keep': Permission denied (This is a local clone across filesystems, which I assume simply copies the objects/ directory from the source repo) Looking at the .keep file that it's trying to copy from the source repo, it is owned by the same user as the corresponding .pack and .idx files, but while the .pack and .idx files have 0440 permissions, the .keep file has 0600 permission (which explains the "Permission denied" error). The .keep file itself contains the following text: receive-pack 6932 on gitmain (where gitmain is the hostname of this server) The timestamp on the .keep file is over a month old, and there is currently no process with ID 6932 running on this server. AFAICS, this indicates that someone pushed this pack over a month ago, and for some reason it failed/aborted, and left the .keep file lying around. From browsing the source, I see that the .keep file is created by receive-pack protect the pack from a concurrent "git gc" while it is being created. However, I have yet to find under which conditions receive-pack will die without removing the .keep file. Some questions: 1. Why does the .keep file have 0600 permissions (preventing a local clone by any other user) 2. Under which conditions will receive-pack leave stale .keep files in the filesystem? Is this a bug? 3. Do I need to scan for and remove stale .keep files in a cron job in order to keep repos healthy and clonable? Thanks, ...Johan -- Johan Herland, <johan@xxxxxxxxxxx> www.herland.net -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html