This allows the use of other non-flocking consumers (e.g. other CAS
implementations) in the same base directory. The '.umoci-*' approach
was suggested by Aleksa [1] as a way to keep Clean from stepping on
other consumers' toes. I'd suggesting using pruneExpire for
ModTime-based backstopping, but Aleksa was concerned about leaking
temporary directories from crashed umoci runs, primarily for
disk-space concerns [1]. The .umoci-* approach allows such abandoned
cruft to be immediately cleaned, without worrying about clobbering
non-umoci consumers and extentions (unless they use .umoci-*
filenames, in which case they deserve it ;).
Aleksa also mentioned that non-umoci consumers might currently be
relying on umoci to clean up their abandoned cruft [1]. But we both
agree that non-umoci consumers should be cleaning up after themselves
and/or providing their own "cleanup anything abandoned by previous
runs of my tool" functionality, and should not be relying on umoci to
do that for them [2,3].
I've gone with .umoci-* instead of Aleksa's .umoci-tmpdir, because I
think the . prefix is a sufficient hint that these directories are
umoci-specific scratch space.
Removal errors (because of insufficient permissions, etc.) seemed like
they should be non-fatal so we could continue to remove other cruft.
However, I didn't want to silently ignore the failed removal. In this
commit, I log those errors with a "warning" level.
The new cleanFile method gives us tighter scoping for the defer lock
release / file close, because those fire on function-exit [4]. With
the old code, we'd keep the removed directory file-descriptors and
associated flocks while Clean processed further directories. With the
new code, we release those resources immediately after we finish
processing the directory in question.
[1]: https://github.com/openSUSE/umoci/pull/198#issuecomment-337889528
[2]: https://github.com/openSUSE/umoci/pull/198#issuecomment-337928272
[3]: https://github.com/openSUSE/umoci/pull/198#issuecomment-337937858
[4]: https://golang.org/ref/spec#Defer_statements
Signed-off-by: W. Trevor King <wking@tremily.us>