forum/Wrong symlink target on usb drivegit-annexhttp://git-annex.branchable.com/forum/Wrong_symlink_target_on_usb_drive/git-annexikiwiki2016-05-10T21:17:50Zcomment 1http://git-annex.branchable.com/forum/Wrong_symlink_target_on_usb_drive/comment_1_9a50df886c0c23ee6f5586bd9f6b61c3/joey2016-05-10T16:17:38Z2016-05-10T16:16:36Z
<p>What OS?</p>
<p>What filesystem is the drive formatted with?</p>
<p>What version of git-annex?</p>
more informationhttp://git-annex.branchable.com/forum/Wrong_symlink_target_on_usb_drive/comment_2_75df13154d3ea662119e9d701a0d9c97/pixunil2016-05-10T17:27:46Z2016-05-10T17:27:46Z
<pre><code>$ lsb_release -a
Distributor ID: LinuxMint
Description: Linux Mint 17.3 Rosa
Release: 17.3
Codename: rosa
$ git annex version
git-annex version: 6.20160505-gddbe008
build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify ConcurrentOutput TorrentParser MagicMime Feeds Quvi
key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
local repository version: 6
supported repository versions: 5 6
upgrade supported from repository versions: 0 1 2 4 5
operating system: linux x86_64
</code></pre>
<p>OS is on both computers the same, on ext4.
The usb drive has 8GB and is NTFS formatted. About NTFS, I wasn't sure, so I left the partition as it was.</p>
<p>I built git-annex with <code>stack</code> three times on top of the latest tag, the version number differed in minor afaik (but can't remember the old ones).
I'm aware that I'm using an unstable version (forgot to mention it, sry about that), but it was on the two latest builds.
I also don't know where the information is what the stable release is…</p>
comment 2http://git-annex.branchable.com/forum/Wrong_symlink_target_on_usb_drive/comment_3_7f2fb4e7f0c0db9f9d9cbb637f02c9ff/joey2016-05-10T17:38:46Z2016-05-10T17:36:53Z
<p>I suppose it must have something to do with NTFS, but I can't reproduce it
on NTFS.. Normally git-annex will refuse to use symlinks on NTFS entirely.</p>
<p>Can you please paste in the whole .git/config file of the repository?</p>
git confighttp://git-annex.branchable.com/forum/Wrong_symlink_target_on_usb_drive/comment_4_f6ee6bfd5d82f0925f0e174b4c75e592/pixunil2016-05-10T17:59:10Z2016-05-10T17:59:10Z
<pre><code>[core]
repositoryformatversion = 0
filemode = false
bare = false
logallrefupdates = true
symlinks = true
[annex]
uuid = ebd16ddb-548c-4078-b35e-087132523924
crippledfilesystem = true
version = 6
[filter "annex"]
smudge = git-annex smudge %f
clean = git-annex smudge --clean %f
# remote and user omitted
</code></pre>
<p>Gotcha! <code>core.symlinks</code> is <code>true</code>!
I set it to <code>false</code> and running <code>unlock</code> works fine, but after <code>lock</code> the file contents gets replaced with the two digits directories (not the three digits directories which are the place where the object is saved). Also, I can't unlock the file afterwards anymore.</p>
<p>However, I would be fine if symlinks work fine on other file system (as mentioned, would be great for saving space and have the access to the files) or other method.</p>
comment 5http://git-annex.branchable.com/forum/Wrong_symlink_target_on_usb_drive/comment_5_e5a152cef3c48ef05cb183907377f128/joey2016-05-10T19:01:09Z2016-05-10T18:08:10Z
<p>Ok, I reproduced the problem. Normally core.symlinks will be false
by on NTFS. You have to manually set it to true to experience
this problem AFAICS.</p>
<p>I was able to lock a file (resulting in a broken symlink) and then successfully
unlock it and the content was back in place.</p>
<p>git-annex always uses the lower case hash directory names when on a
crippled filesystem, since that's more portable and avoids lots of
potential problems. By configuring core.symlinks=true, you make git-annex
support locking files using symlinks, but these symlinks can't point to the
actual content location.</p>
<p>I think it makes sense for git-annex to use the the mixed case hash
directory names when core.symlinks=true even if the filesystem is crippled.
There's some foot-shooting potential, since some crippled fileystems
don't support the mixed-case hash directories. But, you have to manually
set up this configuration. I've made a change along these lines.</p>
comment 6http://git-annex.branchable.com/forum/Wrong_symlink_target_on_usb_drive/comment_6_be59fcc5633b352eefe993871df1ec4a/pixunil2016-05-10T20:45:56Z2016-05-10T20:45:56Z
<p>Thanks for clearing it up, so I guess it was me.
Otherwise, I have some questions:</p>
<ul>
<li>Could I set <code>annex.crippledfilesystem</code> to <code>false</code> or is that dangerous on NTFS?</li>
<li>Do symlinks also on Window work? (direction of the slash)</li>
<li>Wouldn't it be better to modify the link target than the location of the objects?</li>
</ul>
<p>I'm also fine with redirecting me to a FAQ, thanks again for your time and efforts.</p>
comment 7http://git-annex.branchable.com/forum/Wrong_symlink_target_on_usb_drive/comment_7_64e1cdf144a17319831a58b04b22b7ea/joey2016-05-10T21:17:50Z2016-05-10T21:00:06Z
<p>You might be able to unset annex.crippledfilesystem. Or it might cause some
stuff to break. Especially if you access this drive from Windows.</p>
<p>AFAIK symlinks don't work in Windows; at least git-annex does not know how
to create them on Windows. (Windows has symlink-ish things and git might be
able to use them.)</p>
<p>The link target is committed to the master branch, so you need to be able
to check out that same branch in other clones and have it point at the
content. So there can only be one link target used, and by default that's
the mixed case one. See <a href="http://git-annex.branchable.com/tuning/">tuning</a> for how to change that.</p>