forum/What am I doing wrong with move?git-annexhttp://git-annex.branchable.com/forum/What_am_I_doing_wrong_with_move__63__/git-annexikiwiki2016-06-09T20:04:44Zcomment 1http://git-annex.branchable.com/forum/What_am_I_doing_wrong_with_move__63__/comment_1_a49d98426ef8dd17e6cca6b5fba5c9bf/joey2016-05-17T18:13:31Z2016-05-17T18:04:53Z
<p>It sounds like the symlink in the git repository has been changed to point
to some other content that the content it had originally. Since git tracks
past versions of files, you should be able to use <code>git log</code> on the file to
find out when this hapened and you can use <code>git checkout</code> to check out the
original version of the file, or <code>git revert</code> the commit that changed it to
point to the wrong content. The content of the file should still be stored
in the git annex, so you should be able to access it this way.</p>
<p>Now, it kind of sounds like something added the git-annex link for a
file, as it would appear on the FAT filesytem, to git-annex as the new
content of the file. It would certianly be a bug if a git-annex command
did that.</p>
<p>What does <code>git annex info</code> (with no other parameters) report when you run it in the repository on
the USB drive? What filesystem is in use on the USB drive?</p>
Thank youhttp://git-annex.branchable.com/forum/What_am_I_doing_wrong_with_move__63__/comment_2_eeae2f172b4481fcb08745fc28aa4d4e/Gus2016-05-19T11:27:15Z2016-05-19T11:27:15Z
<p>The external unit seems to hold a NTFS. Here is the <code>git-annex info</code> output:</p>
<pre><code>repository mode: direct
trusted repositories: 0
semitrusted repositories: 4
00000000-0000-0000-0000-000000000001 -- web
00000000-0000-0000-0000-000000000002 -- bittorrent
069de9a2-dc53-4c0a-82e0-a61a1f29e6b3 -- stratus PC [stratus]
49b5b3a4-56ac-4cf2-aed9-1c23d3181c97 -- Toshiba USB HDD [here]
untrusted repositories: 0
transfers in progress: none
available local disk space: 4.42 gigabytes (+1 megabyte reserved)
local annex keys: 5556
local annex size: 1.66 terabytes
annexed files in working tree: 6618
size of annexed files in working tree: 1.1 terabytes
bloom filter size: 32 mebibytes (1.1% full)
backend usage:
SHA256E: 6618
</code></pre>
<p>However, <code>git status</code> says:</p>
<pre><code>fatal: This operation must be run in a work tree
</code></pre>
<p>Which is not the same message as "no git found here", but is also not what I expected to see. <code>git log</code> seems to work but says nothing about the file at hand.</p>
<p>On the PC side, however, I can see three commits on the file (I wish the commit message contained the command line with arguments, rather than the less descriptive "git-annex in Toshiba USB HDD").
Using <code>git show</code> and <code>git cat-file</code> I managed to determine the following:</p>
<p>March 4: the initial version of the file was committed.</p>
<p>May 17 11:51: the file's content changed to <code>../../../../../../../../../media/TOSHIBA EXT/annex/.git/annex/objects/kx/3W/SHA256E-s96418--c6164e17d88914b2e6781e2cb8e7b91e9669ddf2d9ee6f5cbb17f3212bccfba4.jpg/SHA256E-s96418--c6164e17d88914b2e6781e2cb8e7b91e9669ddf2d9ee6f5cbb17f3212bccfba4.jpg</code>. This is blob <code>../.git/annex/objects/4z/gf/SHA256E-s245--ae647e7ad31089255413a9290ca9344542f3cd15ecef66884613bf776387633d.jpg/SHA256E-s245--ae647e7ad31089255413a9290ca9344542f3cd15ecef66884613bf776387633d.jpg</code>.</p>
<p>May 17 12:22 the file's content changed again to <code>../../../../../../../../../media/TOSHIBA EXT/annex/.git/annex/objects/4z/gf/SHA256E-s245--ae647e7ad31089255413a9290ca9344542f3cd15ecef66884613bf776387633d.jpg/SHA256E-s245--ae647e7ad31089255413a9290ca9344542f3cd15ecef66884613bf776387633d.jpg</code>, i.e., a reference to the previous object. This is blob <code>../.git/annex/objects/ZQ/WF/SHA256E-s241--f3d7e5d1f788235b8eec0af58cc0c526b112b9e834a47ba7a475876c49dce343.jpg/SHA256E-s241--f3d7e5d1f788235b8eec0af58cc0c526b112b9e834a47ba7a475876c49dce343.jpg</code>.</p>
<p>What else can I do in order to work out what went wrong? Is having concurrent commands manipulating the same repository a bad idea?</p>
I think I have figured out somethinghttp://git-annex.branchable.com/forum/What_am_I_doing_wrong_with_move__63__/comment_3_f2770f86138d9b8489fbf9a25462b4ce/Gus2016-06-05T22:42:17Z2016-06-05T22:42:17Z
<p>When I <code>git-annex drop --force</code> a file from my direct repository, it gets replaced by a symbolic-link-like file, containing a path.
Then, when I <code>git-annex sync</code> the repository to propagate the changes I have made, the file's content gets updated as if the file has been replaced.</p>
<p>My question is then: why does the original file gets replaced by the link-like file when I drop it?</p>
comment 4http://git-annex.branchable.com/forum/What_am_I_doing_wrong_with_move__63__/comment_4_76aa27cdeefb1413baaa1c891ccd4d0d/joey2016-06-09T20:04:44Z2016-06-09T19:51:10Z
<p>The symbolic-link-like file is in fact, a symlink, which is what git-annex
uses to represent an annexed file in git. If your filesystem does
not support symlinks, git writes the link location to a regular file
instead.</p>
<p>git annex drop removes the content of a file from the local repository, but
its symlink remains checked into git. So, the content of the file is
replaced by the symlink in your working tree.</p>
<p>That symlink should be the same thing git already had recorded for the
file.</p>
<p>Based on your earlier comment, it does seem that the symlink standin file
that git uses is being treated as new content for the file, and getting
annexed. That would be a bug.</p>
<p>Is that happening when you run <code>git annex sync</code> on Linux, or is it on Windows?</p>
<p>What else can you tell or show me to help me reproduce your problem?
I've tried setting up an NTFS filesystem, putting a git-annex repository on it, and dropping a file;
git-annex sync did not do the wrong thing when I tried it.</p>