1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
|
[[!comment format=mdwn
username="http://joeyh.name/"
nickname="joey"
subject="comment 4"
date="2013-04-10T22:58:07Z"
content="""
Accessing files from USB on Windows is in scope, but it needs a windows port. Then you could just run git-annex on windows and it would pull the files from USB into your main repository, like the assistant does now on Mac and Linux.
-----
I suspect you don't have actual irreparable data loss. Or, perhaps not. If you really need to get that data back I can try to help.
As I understand what happened, files were sent over the the USB drive, and you had another assistant running in that repository. It seems to have done something wrong, and taken the 1-line standin files that git uses to represent symbolic links when on a FAT filesystem, and committed those to the annex. These new files were then sent back to your original repository.
So, if you look at `git log --status`, you'll find a commit that touched every file, and if you `git revert` that commit, the tree would be returned to how it was before that rogue assistant chomped on it. The actual contents of the files, which is stored in the annex, will probably then have not been lost. Although if you're using direct mode for your repository it is possible to lose annexed content if a file is overrwitten by a newer version, so I can't guarantee that 100%, like I could for indirect mode.
Anyway, I need to fix this misbehavior of the assistant when run on a FAT filesystem, it seems.
------
I have reproduced the bug that the assistant, in a FAT filesystem, commits symlink standin files. It seems to do this at least at startup, to all such standin files. Oddly, I did not see this behavior before when using the assistant on FAT filesystems on Android.
"""]]
|
