I ran into this error during the export of a view to FAT32. At least some of the problems were caused by how git-annex constructed the view's filenames (or temporary transfer filenames), I believe. The filenames are constructed from path elements, which may get truncated, and so the final filenames could end up with trailing spaces. Upgrading to the current version has fixed almost all of those errors.

What appears to continue to be a problem are filenames with percentage signs in them, e.g., foobar 100%.bin. As far as the filesystem is concerned, % characters themselves are obviously fine, because git-annex uses them for all view branch filenames, and the export generally works for them. (For now, I've renamed files to, e.g., foo 100 percent.bin, and it works 100% now. )

git-annex initremote type=git-lfs does set git.remote.url, so it cannot be distinguished if a git-lfs remote got its url set by the user cloning or adding a git remote or by initremote. In the first 2 cases, matching the url against the git configs seems right; in the last case it's not clear what it should do.

This could I suppose be fixed by documenting better that it sets git.remote.url. So the user knows that they set the config with that command, and won't be surprised that Remote.GitLFS matches the remote url against the git configs.

de52af5d334c55bb64dc2c5223c476b19c200a6c implemented http.<url>.* matching in git configs, which is the necessary (and quite fiddly!) groundwork for this.

git's http.<url>.* documentation includes this:

The URLs that are matched against are those given directly to Git com‐
mands. This means any URLs visited as a result of a redirection do not
participate in matching.

This raises further questions about when it would make sense for git-annex to use the config. I wrote more about this problem over at Support per SITE http.SITE.sslCAInfo etc.

What I am leaning toward is only supporting these configs for git remote urls, and not for all the other urls that git-annex uses.

I got as far as implementing a git compatible config matcher, in 6f43e386788eb01e944f98df0d6ed6eb79b84e76.

But, it's difficult to see a way to implementing this for http.sslCAInfo and http.sslCAPath. It needs to somehow be fed into http-client's Manager. But a Manager is set up outside any code path that knows what url is being downloaded. And nothing in the Manager API lets it override its ConnectionContext based on the url being requested.

I think that UrlOptions would need to change httpMananger to an IO action that takes the url. And then to be performant, there would need to be caching of Managers, so that once a manager is created using a given http.sslCAInfo or http.sslCAPath, that same Manager keeps being used for other urls that use the same config values.

But the fun doesn't stop there, because Manager is a core data type used by other haskell libraries. Eg, in Remote.S3, git-annex passes a Manager into aws, and so has no visibility about what urls that Manager will be used for.

And that shades into another problem -- the http.<url>.* documentation includes this:

The URLs that are matched against are those given directly to Git com‐
mands. This means any URLs visited as a result of a redirection do not
participate in matching.

If git-annex follows that, it would need to distinguish when an url is user-provided enough to use that config and not.

When using Remote.GitLfs to download an object, there is essentially a redirect via the git-lfs protocol. Should that url be matched against the git config? Seemingly not. But in the aws case, the S3 publicurl= value was provided as an input to git-annex annex command. So it seems that it should.

What does it mean for the url to be given directly to a git(-annex) command? The git clone url certianly was. The S3 publicurl= value was provided by someone but it may not be the user using the remote now. And similarly a git-annex get --from web may be run by someone other than the person who ran addurl.

And git-annex importfeed discovers other urls, but is otherwise equivilant to the user running git-annex addurl themselves on those urls. In one case the user gave the url to a git-annex command, and in the ther case they did not. It does not really make sense for git-annex to distinguish those two cases, but either thing it picks will violate the git documentation.

Now, git-annex could choose to diverge from git and always use the config. But bear in mind that extraheader config is asking some very similar questions about another http. config. Which could be a security hole if it exposes the config to the wrong urls.

What might make sense would be for git-annex to support http.<url>.sslCAInfo and http.<url>.sslCAPath only where git does. So for a git remote url, and not for anything else. I think that would also make sense for the extraheader config.

Now that external special remotes can support importtree, it does seem like all that is missing to have this in an external special remote is a way to set thirdPartyPopulated.

rclone would be another use case, some of its remotes support server-side generation of md5, sha1, or other hashes.

I feel like I had asked similar question in the past but failed to find it or an answer

Indeed it feels like it would be great to be able to just declare to always do only "unlocked" mode operations in a given git-annex repo, and thus potentially keeping it always in the "unlocked" mode (even when on system with symlinks support), but without requiring any adjusted/ "synchronization" altogether.

The external special remote interface is implemented, so I am closing this.

See new make more special remotes support importtree