Recent comments posted to this site:

So I ran:

git annex --numcopies=0 dropunused 1-2
dropunused 1 ok
dropunused 2 ok
(recording state in git...)

Which is fine, then:

cat Harry\ Brown\ \(2009\)\ 1080p.mp4
/annex/objects/WORM-s2046008512-m1537755616--Harry,32Brown,32,402009,41,321080p.mp4

And that is strange.

$ rm Harry\ Brown\ \(2009\)\ 1080p.mp4
override r--r--r--  jasonb/staff for Harry Brown (2009) 1080p.mp4? y
$ cp -a ~/Downloads/Harry\ Brown\ \(2009\)\ 1080p.mp4 .
$ git annex add Harry\ Brown\ \(2009\)\ 1080p.mp4
add Harry Brown (2009) 1080p.mp4 ok
(recording state in git...)
$ ls -l Harry\ Brown\ \(2009\)\ 1080p.mp4
lrwxr-xr-x  1 jasonb  staff  162 Apr 17 21:24 Harry Brown (2009) 1080p.mp4 -> .git/annex/objects/XV/Wx/WORM-s2046008512-m1555550686--Harry,32Brown,32,402009,41,321080p.mp4/WORM-s2046008512-m1555550686--Harry,32Brown,32,402009,41,321080p.mp4

And that's what I expected. I'm lost as to what happened.

Comment by jasonb Thu Apr 18 01:36:04 2019

Dug a little into implementing this.

One problem is that things like git annex dead look up a name in the remote list, and then use the uuid of the returned remote. But if remote foo has sameas=bar-uuid, then the remote in the remote list that it looks up will have that uuid, and so the uuid that will be marked as dead is almost certianly not the one that the user expected.

And the user can't pass the masked uuid of the sameas remote to git-annex dead, because there will be no remote in the list with that uuid.

And for that matter, the user is not likely to know the masked uuid, because things like git annex info won't display it..

Another gotcha is that the user might make remote B with sameas=A-uuid, and remote C with sameas=B-uuid. Which really needs to resolve to A-uuid, so it needs to do multiple lookups, but then a sameas loop becomes a problem.

Comment by joey Tue Apr 16 17:09:39 2019

Thanks for your reply.

One example is when working with scanned images and digitized sound recordings:

The original file names [unmodified] are needed to source which analog original they are paired with in an archival system beyond my control, but as I manually work with these files, the structure changes to [modified], which I'd like to be the repo's default state. So when new data arrives (via a remote) new files should be checked into the [unmodified] state with their original file names, and then be worked on in the [modified] state. I'd like this [unmodified] state to be singular, as opposed to checking out a specific commit for a specific subset of files.

Another, perhaps simpler, example is music files: They come in various combinations of file and folder names as they are ripped from CD or downloaded. I'd like an external program (beets) to handle organizing these files (the symlinks, really) into a folder structure, as I need them to be presented in a particular way to an indexer/player, i.e. as [modified]. So again, I'd like to ingest (from a remote) into git-annex using the original file names (if needed at a later point) while still letting beets move things around structurally. At some point in time, I'd like to be able to easily hop back to my music library in its [unmodified] state without having to find the particular point in time when I added that particular subset.

I'm trying to achieve this with as little manual massaging as possible.

Metadata and views are a great option to have, but from what I understand not the right fit here.

This was long but I hope it made some sense.

Comment by strmd Tue Apr 16 15:12:57 2019

Depends on how often and what "work" is done with the original filenames. Can you explain more what you are trying to do?

Perhaps you can use metadata/metadata views.. though this would give you the original filename as a directory, containing a file with the current filename. e.g. ~/annex/originalfilename.txt/currentfilename.txt

Comment by CandyAngel Tue Apr 16 13:10:03 2019
Great, thanks for the confirmation.
Comment by mario Tue Apr 16 11:07:10 2019

git add and git annex add do both behave the same on symlinks (at least, in indirect annexes).

They are just staged (then fixed on commit, if required).

Comment by CandyAngel Mon Apr 15 07:34:21 2019

curl -v shows the problem response

< Server: openresty/1.7.10.1
< Date: Wed, 10 Apr 2019 13:57:10 GMT
< Content-Type: application/octet-stream
< Content-Length: 773788987
< Connection: keep-alive
< Last-Modified: Mon, 11 Mar 2019 16:35:02 GMT
< ETag: "5c868e36-2e1f153b"
< Accept-Ranges: bytes
< Strict-Transport-Security: max-age=15768000; includeSubdomains;
< preload
< X-Frame-Options: DENY
< X-Content-Type-Options: nosniff

It looks like the server is sending "preload" on its own line rather than being part of the Strict-Transport-Security header.

Just in case, I found another url that uses HSTS preload, and git-annex can download that:

joey@darkstar:~>curl -v -o foo https://www.torproject.org/ 2>&1 | grep preload
< Strict-Transport-Security: max-age=15768000; preload
joey@darkstar:~/tmp/c>git annex addurl https://www.torproject.org/
addurl https://www.torproject.org/ 
(to www.torproject.org_) ok

The web server is probably violating standard HTTP to some extent with that response. Of course, it's possible to parse the response less strictly and not fail on the malformed header. Still, fixing the web server is probably the fastest way to fix the immediate problem (as well as make HSTS preloading actually be used).

Issue filed on http-client, https://github.com/snoyberg/http-client/issues/398 with a prospective patch.

I don't see any changes to git-annex that can help with the problem, so I'll close this bug report.

Comment by joey Wed Apr 10 13:58:03 2019
   Each - is matched against the set of refs accu‐
   mulated  so far.  Any matching refs are removed
   from the set.

It matches against the literal text of the ref that was added, so if you use "+*", it adds refs/heads/master, and then to remove that, you need "-refs/heads/master" not "-master". On the other hand, "+master:-master" results in "master" being added and then removed.

Clarified to mention that it matches by name; I suppose perhaps you were thinking it matches based on what sha1 the ref name resolves to. The reason it doesn't do that is that it would be surprising for "+foo:-master" to not include ref foo just because it happens to currently have the same sha1 as master does.

Comment by joey Tue Apr 9 15:16:12 2019
Comment by joey Tue Apr 9 15:12:22 2019