Please describe the problem.
Using the S3 special remote with version support enabled (versioning=yes) leads to a bit of a strange effect with multiple annex import calls.
First import from an existing bucket is fine. Now, if there were changes done to a file in the bucket and one runs annex import again, git-annex will record that the old version of said file is gone from the remote, requiring a git annex fsck to be called right after that import to fix it again. That seems a bit strange given that this versioning support comes with a "native" special remote.
I suppose that's probably a more general issue with how import/export works, since there's no way for a special remote to communicate to annex whether two different versions of the same file (same remote path, but different key) would overwrite each other. Neither an importtree nor an exporttree remote has a way to tell annex whether and how the availability of a previous key associated with the same remote path was affected.
What version of git-annex are you using? On what operating system?
Observed with several versions from 8-10 on linux. As laid out above, I strongly suspect this is true for all versions.
Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
Lots. I love git-annex.
This looks like a simple fix. After importing from a versioned remote, it can just skip updating the location logs to remove the keys that are not present in the current tree. The same as is already done when exporting to a versioned remote. I've made that change.