git-annex stored a bunch of files on a S3 bucket under foo/ and now I'd like to "move" them to bar/.

Assuming I manually "move" the files on S3 to bar/, would git annex enableremote s3 fileprefix=bar/ be enough to access the existing encrypted files?

Or does fileprefix influence the S3 location of future files only?

This issue still exists today with version 10.20260213

I came across it while trying to run a docker build from macOS host to a linux image. All annex symlinks became broken inside of the image. Thank you for reporting this!

I've implemented re-checking of the annex.url config when remote.name.annexUrl is configured to an annex+http url.

Going to close this, but if you also need it when remote.name.annexUrl is not configured, let me know.

Would this include re-checking when remote.name.annexUrl is unset?

If that would mean checking on every use of the remote, it seems too often.

And even Debian stable now includes a new enough git-annex to support p2phttp, so the benefits of that check are more limited now to detecting server-side changes.

Given that the clone happened in the knowledge that "dumb http" was the only supported http protocol and read only, I am now questioning if such a automatic upgrade to p2phttp would really be needed, or even desirable

I think that's a good point.

So I'm inclined to make this todo only about re-checking when remote.name.annexUrl is configured to a annex+http url and it fails to connect.

git-annex will filter the tree it exports to only the files that are configured to be preferred content of the remote. So you could do this:

git annex wanted android 'include=album/*'
git-annex export master --to android

See git-annex-preferred-content for details about the syntax, but basically you can extend that to as many directories as you want, separated by "or"; it will include any files in any of those directories.

How do I create a tree that contains the subfolder itself too?

Worth noting that is a general git question really, with several valid answers that don't involve git-annex at all. (One easy one is to check out a new branch, git rm everything except the subfolder, and git commit.)

And once you have such a tree stored on a git branch, you can pass that branch to git-annex export. So that's an option if you don't want to need to deal with git-annex's own filtering features.

This is a simple failure to refill a TMVar on use, so easy to fix.

T the bug has always been there since the first release of Remote.Mask. I am as surprised as you that apparently none of us tried it with multiple files before.

Reproduced. Note that {1..4} is a bashism or something and didn't work when I used it in a shell script, but seq 1 4 worked.

FWIW, I did add a note to the git-annex-export man page that git-annex expects to be the only thing writing to an exporttree=yes remote unless importtree=yes. So hopefully there will be less confused users. However, I'm doubtful that will be enough to avoid all confusion.

So, I've also made it display a warning in this situation.

This bug report appears to have been generated by an LLM.

I do not appreciate and will not engage with LLM generated content, so if you would like this bug to be looked at and fixed in a timely manner, please use your own words.

I will delete this bug as probably LLM generated if you do not do so within the next few days.