On Thu, 4 Dec 2014, Nikolaus Rath wrote:
[snip]
That's the reason for the exception on umount then. mount.s3ql
currently isn't able to handle that. The existing data is ignored as you
say, but mount.s3ql attempts to rmdir the cache directory after
unmounting. That fails if there are still files in there.
Normally, the only way for this directory to exist is if the file
system was not unmounted cleanly. In this case mount.s3ql will refuse to
start, and you have to run fsck.s3ql instead. fsck.s3ql will then
clean-up the cache directory, and mount.s3ql will start with an empty
cache.
In your case...
It should be noted that the fsck run on this file system was not run
from my local machine, but from the remote server, so when I mount this
on my local machine, it says something to the effect that the local
cache is out of date, and then proceeds to download and unpack the
current file system information from the remote server.
.. you have neatly circumvented the clean-up of the cache directory.
mount.s3ql now believes the file system is clean, but there is actually
a cache directory with files in it.
This is certainly a bug in S3QL, but I have to think about what the
correct behavior for mount.s3ql actually would be. Refusing to mount
would be odd, because the file system is indeed clean. But silently
deleting the data in there intuitively sounds like a dangerous choice as
well.
While I don't know what is in the cache, it would seem to me that once the
file system has been cleaned elsewhere that the cache data would cease to
be usable for any purpose (other than forensic) as it would be
inconsistent with the state of the file system. If so, I can't
see that you have any real choice but to discard it. Informing the user
that you have data available but they can't use it for anything would
serve no purpose. You do provide warnings about multiple computers,
including a warning when I run fsck on a computer which was not where the
file system was last mounted.
FWIW.
At least this gives me a simple work-around for the bug :-)
Shannon C. Dealy | DeaTech Research Inc.
de...@deatech.com | - Custom Software Development -
USA Phone: +1 800-467-5820 | - Natural Building Instruction -
numbers : +1 541-929-4089 | www.deatech.com
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
