forum/Problems with FAT linksgit-annexhttp://git-annex.branchable.com/forum/Problems_with_FAT_links/git-annexikiwiki2016-11-03T18:13:54Zcomment 1http://git-annex.branchable.com/forum/Problems_with_FAT_links/comment_1_1628c68ef7bdaedb01fcb897a447bb91/joey2016-10-26T18:20:41Z2016-10-26T18:18:57Z
<p>I don't know what you mean when you say "FAT link". Do you mean it's a
regular file that contains what looks like the pointer of a symlink?</p>
Yeshttp://git-annex.branchable.com/forum/Problems_with_FAT_links/comment_2_734850345a66d5df38c468ffaa1182cd/Gus2016-10-27T10:28:23Z2016-10-27T10:28:23Z
<p>Exactly, the files that perform the role of symlinks on filsystems that do not support them adequately.
The files that have only things like</p>
<pre><code>../../.git/annex/objects/jF/fq/SHA256E-s496058976--a687727e1b0e7cab74fa160f2dc17d0fbbffcf44939fc44e59f803de21617e19.avi/SHA256E-s496058976--a687727e1b0e7cab74fa160f2dc17d0fbbffcf44939fc44e59f803de21617e19.iso
</code></pre>
<p>I do not know the proper name for them. Also, the git-annex standard information:</p>
<pre><code>git-annex version: 6.20160613-g1e4e6f4
build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify XMPP 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: 5
supported repository versions: 5 6
upgrade supported from repository versions: 0 1 2 3 4 5
operating system: linux x86_64
</code></pre>
<p>Thank you very much for all your work and dedication to git-annex.</p>
Add more informationhttp://git-annex.branchable.com/forum/Problems_with_FAT_links/comment_3_2728cd609cb5e792d1dc722d450e4c8d/Gus2016-10-27T12:05:39Z2016-10-27T12:05:39Z
<p>I looked up more information, and this is getting strange. I verified the time of last change for the "FAT link" files in my indirect repository. <strong>All</strong> of them say 2016-03-13 11:43:55.3, including the two files that, <code>git log</code> says were last manipulated in August 9, and reside in a different area of the repository.</p>
<p>Here is my <code>git log</code> has to say about this particular moment:</p>
<pre><code>commit 2fe1a5834031838563acda9cbdb33ca4c13ec413
Date: Sun Mar 13 11:43:34 2016 +0000
git-annex in Toshiba USB HDD
</code></pre>
<p>I wish these logs were more descriptive. <img src="http://git-annex.branchable.com/smileys/ohwell.png" alt=":-/" /> If it said the hostname, $PWD and the command line, I could follow along.</p>
comment 4http://git-annex.branchable.com/forum/Problems_with_FAT_links/comment_4_0a5f0239b3b6376672c8d91eaf68a460/joey2016-10-31T18:46:58Z2016-10-31T18:32:54Z
<p>There have been some problems some time ago with the symlink bit getting
lost on information in the git repository when git-annex makes commits
on a FAT filesystem.</p>
<p>That was resolved in early 2014, and there's a test case to make sure that
particular problem doesn't come back, so make sure
you are not using a git-annex version from before then.</p>
<p>Please check that core.symlinks is set to false. Can check it by running
<code>git config core.symlinks</code> and see if it outputs "false"</p>
<p>I have tried to reproduce on FAT, <code>git annex drop</code> followed by <code>git annex
sync</code>, does not seem to do anything to the symlink here. If you can
reproduce such a thing happening, it's certianly a bug.</p>
Why overwrite the files?http://git-annex.branchable.com/forum/Problems_with_FAT_links/comment_5_3c9dd1e2586b27911422066ca71f5298/Gus2016-11-03T18:13:54Z2016-11-03T18:13:54Z
<p>Thank you for looking into my problem.</p>
<p>My version of git-annex is recent, and <code>core.symlinks</code> is set to <em>false</em>. So it must have been something else. I too have not been able to reproduce the error. It seems this problem will remain a mystery for now.</p>
<hr />
<p>On a related matter, when I <code>git-annex drop</code> a file on FAT direct mode, the file is replaced by the symlink-like file. I would like to understand the rational for that. I think that, on the past, <code>git-annex</code> may have added that file (or better, <em>I</em> may have done so, with a less careful <code>add</code>) and replaced the file's contents.</p>
<p>I think that replacing the "good" data of a file with something "useless" is counter-intuitive, and may trip people. I would expect <code>git-annex drop</code> to either remove the file or to leave it alone for manual removal or manipulation.</p>
<p>As you seem quite careful about the possibility of data loss, it seems there is a relevant detail that I am failing to grasp. Even if the "proper" way to remove a file in FAT direct mode is to use <code>rm</code>, <code>git-annex drop</code> does not seem like a bad choice.</p>
<p>Would you mind saying a few words about this, Joey? I feel a bit uneasy without understanding <em>why</em> the file is overwritten.</p>