comment

doc/bugs/addurl_+_metadata_on_Windows_doesn__39__t_work/comment_1_831dc2185919865d418b29cd06ef42be._comment

@@ -0,0 +1,42 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-10-26T16:44:21Z"
+ content="""
+Windows is not needed, this will happen in a 
+repository where `git annex adjust --unlock` has been run.
+
+A simpler example:
+
+	joey@darkstar:~/tmp/t2#master(unlocked)>git-annex addurl --batch
+	http://google.com/
+	addurl http://google.com/
+	(to google.com_) ok
+	^Z
+	joey@darkstar:~/tmp/t2#master(unlocked)>git-annex metadata --batch --json
+	{"file":"google.com_","fields":{"author":["bar"]}}
+
+I'm not sure if this is a bug, because it's documented to output a blank
+line when batch mode is provided a file that is not an annexed file, and
+the file is not an annexed file yet due to the pointer not yet having been
+staged in git. Which is needed, when in an adjusted unlocked branch, for
+git-annex to know that this is an annexed file.
+
+When the file is locked, it just stats the symlink, so the fact that the
+symlink is not yet staged in git doesn't matter.
+
+It does not seem to make sense to have addurl update the index
+after each file it adds, because that would make addurl of a lot
+of files unncessarily slow.
+
+So, I think if anything is changed, it would need to be a change to make
+the behavior with unlocked files consistent with the behavior with locked
+files. Eg, when the symlink is not yet staged in git, treat it as a
+non-annexed file. Which is also consistent with other handling of such
+files by git-annex when not in batch mode.
+
+The solution for your program, though, seems like it will be to end the
+git-annex addurl process before trying to set metadata on just-added files.
+Or, alternatively, to use addurl with --json, extract the key, and set the
+metadata of the key.
+"""]]