Please describe the problem.
This is a one-off thing, not a reproducible bug. It was just so weird that I wanted to make a note of it in case somebody else had the same problem and it was reproducible.
I have a remote on the a USB drive which I mount once in a while on /Volumes/TOSHIBAEXT which has a remote on /Volumes/TOSHIBAEXT/annex. It's a remote which I created by hand using "git clone" a long time ago, not something the assistant set up for me.
Anyway, today the assistant kept reporting that it could not sync to it. I didn't know why, because I checked in my Finder sidebar and it showed a mounted drive called TOSHIBAEXT. It's only when I checked with the command line that I noticed something was up! There was now an ordinary directory at /Volumes/TOSHIBAEXT/annex. This had apparently been created at some point when the drive was unmounted, so when it re-mounted, because there was a directory in the way, it re-mounted at "/Volumes/TOSHIBAEXT 1". But it was displayed in the finder sidebar as just "TOSHIBAEXT" anyway because the finder hides this workaround from the user for whatever reason.
Presumably git-annex assistant at some point, for some reason, created an ordinary directory where it expected to find the annex.
I wonder if this may have to do with the fact that this is a non-bare, created-by-hand repo, from before I was using the assistant, not a normal bare remote that the assistant would have created for me if I'd been using the webapp.
What steps will reproduce the problem?
I've only seen it once, and report the bug not as an outstanding issue but only as a heads-up that this has ever happened.
What version of git-annex are you using? On what operating system?
git-annex version: 4.20130501-gb61740e
OS X lion (10.7)
Please provide any additional information below.
I wasn't logging when this happened.
Again, just a heads-up; I'll keep my eye open for this happening again and post more info if it does.
Huh. This happened a second time today. I'll try and catch it in the act, and make a proper bug report, when I get a chance.
Still not sure this is a bug rather than just a peculiarity of how I have things set up.
Hmm.. One way I can think that this could happen is if git-annex was running, and doing something in the repository on the drive that involved making a directory, and the drive was removed. There are several places in git-annex where it has code, like this:
Is the repo you have on the drive a direct mode repo by any chance? This is the only obvious way I can see that would cause it to create just the top level directory of the repository, and not a deeper directory tree like
.git/annex/tmp/The assistant also has a MountWatcher that detects when repositories that were not accessible get mounted, but it does not do anything to stop the repository being used when its drive gets unmounted. Even if it did, it couldn't go anything about code that is already running using the previously mounted repository. However, as things stand, it would probably also be possible for the drive to be removed, and some time to pass before an action was run that tried to do something to the no longer present repository. So making the mountwatcher disable repositories when drives are unmounted would at least make this window narrower.
It's possible, even likely, that there were indeed more directories and I didn't notice because they were hidden and I just looked at them with a vanilla "ls" command with no flags like "-a".
So it's probably exactly what you're thinking --t here was something going on, a transfer queued or something, that I didn't realize was happening and I removed it and it went and created the directory as if it were there.
I saw this too, today. The repo in my case was created via the webapp, using the 'usb key' option. I was messing about with deleting repos and had turned off synchronisation for the repo on the key as I didn't have it inserted.
I only just stumbled on this bug report after removing the repository from the key entirely, so it's difficult to define the reproduction steps.
I just did this. The key was mounting at /Volumes/VERBATIM4. Just after unplugging without unmounting, that directory was gone. When I made the change that could be synced, I got a /Volumes/VERBATIM4 directory. The directory tree structure is similar to but different from the structure on the usb key, see below.
Now when I try to plug it in again os/x will spot the potential conflict and mount the key at /Volumes/VERBATIM4\ 1.
If I instead rm -rf /Volumes/VERBATIM4 and then replug the usb key, everything syncs as expected.
Version: 4.20130723-ge023649 (os/x 10.8)
Build flags: Assistant Webapp Pairing Testsuite S3 WebDAV FsEvents XMPP DNS
Tree structure of the phantom directory:
Any hint about how to stop this from happening again? This time I think I was careful and tried to stop git-annex, however I got ghosts. Whats the correct way to unplug the drive?
My scenario is the following, I have two repos on HDD synced with a USB drive. I want to sync them to the USB drive from time to time when I plug it. I want a safe way to unplug drive without getting these ghost directories.
This time, I entered both directories in the HDD and made a git-annex assistant --stop, but after doing a ps aux | grep git-annex I still see many processes running so I'm not sure if I truly stopped it. The webapp gives me the impression of working on a per-repo basis, so I miss having some sort of general feedback about git-annex. Something like: "at the moment you are syncing repos A and B" or "idle". So I never have a clue about whats going on. I'm trying to set up this since long time, and I'm a very capable unix guy, and I still have the feeling that I can't trust git-annex. I really like the tool but I'm not sure how to use it properly. Thanks in advance.