Maybe this patch is ok to apply without worrying about those other cases. --sameas is not guaranteed to work for all combinations of special remotes and that's why multiple remotes accessing the same data store documents combinations that work.

So it could just be documented that this one specific combination also works. And it happens to be a useful combination to support. If we later want some other combination like import from rsync followed by get from sameas directory to also work, the extra code can be written then to support it. (By eg making Remote.Directory not implement importActions using exportImportActions, or making its retrieveExportWithContentIdentifier not fail when the [ContentIdentifier] list is empty)

Following is a small patch that makes import from directory, followed by get from the sameas rsync work.

Note that, import from rsync followed by get from sameas directory won't work with this patch. The reason is that directory special remotes support importree+exporttree. And even if they are only configured with exporttree, they currently verify ContentIdentifiers when retrieiving. And when no ContentIdentifier is known, it will fail.

So, applying this patch seems like it would need remotes like directory to have a separate implementation of importActions, rather than the current way that exportImportActions is used to implement importActions. There are not too many remotes that support importtree+exporttree, so maybe that is worth doing.

The other limitation of the patch is that import from rsync followed by get from sameas directory that is configured with importree+exporttree still won't work. And this approach cannot deal with that case.

diff --git a/Remote/Helper/ExportImport.hs b/Remote/Helper/ExportImport.hs
index 23bd86c1ec..7db9ddebfb 100644
--- a/Remote/Helper/ExportImport.hs
+++ b/Remote/Helper/ExportImport.hs
@@ -454,18 +454,13 @@ adjustExportImport' isexport isimport isexportimport annexobjects r rs gc = do

    retrieveFromImport getlocs ciddbv k af dest p = do
        cids <- getkeycids ciddbv k
-       if not (null cids)
-           then getlocs $ \loc ->
-               -- retrieveImport does not guarantee that
-               -- the file it retrieves has the content
-               -- identifier, so it must be strongly
-               -- verified.
-               stronglyverify $
-                   snd <$> retrieveImport (importActions r) loc cids dest (Left k) p
-           -- In case a content identifier is somehow missing,
-           -- try this instead.
-           else retrieveWithoutContentIdentifier $
-               retrieveFromExport getlocs k af dest p
+       getlocs $ \loc ->
+           -- retrieveImport does not guarantee that
+           -- the file it retrieves has any content
+           -- identifier, so it must be strongly
+           -- verified.
+           stronglyverify $
+               snd <$> retrieveImport (importActions r) loc cids dest (Left k) p

    retrieveWithoutContentIdentifier a
        | isexport = a

A use case for this is having a directory special remote that is --sameas a rsync special remote. git-annex import --fast from the directory special remote imports the tree and that avoids needing to import from the rsync special remote, which would be much slower for a large data set.

A second import step would be acceptable in this situation. The user would need to make sure that the files on the remotes are unchanged from the directory import when running the rsync import. This seems like it could be handled as a special flag to git-annex import.

When this was filed in 2020 I'm not sure why it would do that, but later on ba7ecbc6a9c3763e8152e4f46522d14a4ee2b59d made quiesce call Database.Keys.closeDb and so this is entirely the expected behavior.

There is certainly the potential for less frequent use of quiesce avoiding this overhead though. It could eg wait 1 second after last use before quiescing.

This happens because the meaning of a content identifier is dependent on the implementation of the special remote. Using a content identifier generated for a directory special remote with a rsync special remote will not work.

So, for the --sameas remote, the content identifier is accessed using its annex-config-uuid rather than the annex-uuid. And that's why it says no content identifier is recorded, since none has been stored using the annex-config-uuid.

For this to work there would need to be another step taken to record the content identifiers for the --sameas remote. Which could be something like git-annex import from it -- except when I tried doing that, it doesn't record them, because it skips over already imported files.

I doubt that needing a second import step would meet your needs though?

It may be that the best fix for this is to prohibit initializing a --sameas remote with importtree=yes.

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.