Be robust against unexpected files in refs/, e.g. ".latest_rsync"

[parasense]

I observed the error when updating the summary file:

$ sudo ostree summary -u --repo=/mnt/redhat/nightly/Atomic/ostree/repo/
[sudo] password for jdisnard: 
error: No such metadata object .commit

The ostree is an rsync copy of my production repo, but contains a lot of little files named .latest_rsync , which is an artefact of how my replication tool deploys the ostree repo to a CDN. I guess some scheme to avoid re-uploading contents. Anyways, after running the above cmd under strace, I observed ostree attempting to open those files....

fcntl(12, F_GETFL)                      = 0x38800 (flags O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_NOFOLLOW)
fcntl(12, F_SETFD, FD_CLOEXEC)          = 0
getdents(12, /* 4 entries */, 32768)    = 120
openat(8, "rhel-atomic-host/7/x86_64/.latest_rsync", O_RDONLY|O_NOCTTY|O_CLOEXEC) = 13
fstat(13, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
read(13, "", 16)                        = 0
close(13)                               = 0
openat(8, "rhel-atomic-host/7/x86_64/standard", O_RDONLY|O_NOCTTY|O_CLOEXEC) = 13
fstat(13, {st_mode=S_IFREG|0644, st_size=65, ...}) = 0

so on a whim I removed all the .latest_rsync files from my copy of the repo, and then the summary file update worked afterwards. Clearly my repo was corrupted by these tiny files, and I know the fix is to simply remove them all, but I figured ostree might be made more resilient against such things.

[cgwalters]

Sure, easy enough. PR in #1286

[parasense]

Thanks, and meanwhile I'm filing a bug against my deployment tool, to ask they stop using dot files and perhaps use extended attributes or some other scheme to track uploads. Appreciate the quick turn around, thanks again.