gueux [Thu, 19 Nov 2020 22:14:24 +0000 (22:14 +0000)]
rename bugs/adjust_--unlock_implies_all_files_set_as_modified.mdwn to bugs/after_adjust_--unlock_implies__44___a_lot_of_files_are_reported_as_modified.mdwn
Joey Hess [Thu, 19 Nov 2020 20:36:37 +0000 (16:36 -0400)]
convert processTranscript to use hGetLineUntilExitOrEOF
It does use it on both stdout and stderr. It seems unlikely the problem
could really affect stdout, but the unix implementation of it combines
both into a single handle in any case.
Joey Hess [Thu, 19 Nov 2020 20:13:31 +0000 (16:13 -0400)]
convert to use hGetLineUntilExitOrEOF
It looks to me like the old code would have already dealt with the case
of ssh starting a ssh daemon that inherits stderr and keeps it open.
The ender thread closed the handle, which would unblock the other thread
and let it exit. Using hGetLineUntilExitOrEOF makes this more explicit
that it's dealt with and simplifies the code.
Joey Hess [Thu, 19 Nov 2020 18:41:33 +0000 (14:41 -0400)]
preserve other headers when adding resume header
It had lost the hAcceptEncoding header that is set as part of the
overriding of http-client's default decompression of compressed files.
Seems likely that would have caused resuming of compressed files to fail
in some cases.
This commit was sponsored by Brett Eisenberg on Patreon.
Joey Hess [Thu, 19 Nov 2020 18:03:00 +0000 (14:03 -0400)]
don't rely on exception for http 416
Fix a bug that could make resuming a download from the web fail when the
entire content of the file is actually already present locally.
What a mess that Request can throw exceptions or not, depending on how
it's configured. Makes it very hard if you need to handle some specific
http status codes in a function like this! Implementing everything two
ways did not seem appealing, if possible at all, so I decided to
override the Request if it did come configured to throw exception on
non-2xx http status. Other exceptions, like from http-client-restricted,
or due to a redirect to a non-http url, still get thrown.
This commit was sponsored by Luke Shumaker on Patreon.
Joey Hess [Thu, 19 Nov 2020 16:50:25 +0000 (12:50 -0400)]
fix windows assistant upgrade glitch
Prevent windows assistant from trying (and failing) to upgrade itself,
which has never been supported on windows.
The new windows build is made with UPGRADE_LOCATION set, which enabled this
code path that had never run on windows before, and doesn't work. I don't
want to try to support self-upgrade on windows, or generally on other OS's
than the ones where its working, so added a check for that. This way the
build can keep setting UPGRADE_LOCATION and if some later git-annex does
learn how to upgrade itself on some OS, it won't need changing the build
setup.
Joey Hess [Thu, 19 Nov 2020 16:20:18 +0000 (12:20 -0400)]
fix removeLink on windows
This removeLink was introduced in commit e505c03bccdc6567cd517a6ddaf70a411489473d, which replaced code
that used removeFile on Windows. So, I know git-annex did not used to do
anything other than removeFile on Windows. If there were symlinks it
wanted to remove, this would not work on windows, but of course it does
not use symlinks on windows.
Joey Hess [Wed, 18 Nov 2020 18:48:50 +0000 (14:48 -0400)]
newline mode (mis)handling for windows
Unfortunately, there is no hGetNewLineMode. This seems like an oversight
that should be fixed in ghc, but for now, I paper over it with a windows
hack.
Joey Hess [Wed, 18 Nov 2020 18:21:47 +0000 (14:21 -0400)]
working hGetLineUntilExitOrEOF
The problem with the old version seemed to be that hWaitForInput blocks
rather than timing out when being run concurrently with hGetLine on the
same handle.
This passes the bench test, and also works when run concurrently on
different handles.
Joey Hess [Wed, 18 Nov 2020 16:23:15 +0000 (12:23 -0400)]
bench test for hGetLineUntilExitOrEOF
This seems to show that hWaitForInput does not seem to behave as
documented. It does not time out, so blocks forever in this situation.
This is with a 0 timeout and with larger timeouts. Unsure why, it looked
like it should work.
Joey Hess [Mon, 16 Nov 2020 18:09:55 +0000 (14:09 -0400)]
annex.adjustedbranchrefresh
Added annex.adjustedbranchrefresh git config to update adjusted branches
set up by git-annex adjust --unlock-present/--hide-missing.
Note, in a few cases, I was not able to make the adjusted branch
be updated in calls to moveAnnex, because information about what
file corresponds to a key is not available. They are:
* If two files point to one file, then eg, `git annex get foo` will
update the branch to unlock foo, but will not unlock bar, because it
does not know about it. Might be fixable by making `git annex get
bar` do something besides skipping bar?
* git-annex-shell recvkey likewise (so sends over ssh from old versions
of git-annex)
* git-annex setkey
* git-annex transferkey if the user does not use --file
* git-annex multicast sends keys with no associated file info
Doing a single full refresh at the end, after any incremental refresh,
will deal with those edge cases.
Joey Hess [Mon, 16 Nov 2020 15:21:33 +0000 (11:21 -0400)]
split out Annex.Content.Presence
This will let a module that Annex.Content imports use inAnnex.
Unsure yet if I will need that, but this split still seems to make
sense, and Annex.Content was way too long so splitting it is good.
Joey Hess [Mon, 16 Nov 2020 14:09:25 +0000 (10:09 -0400)]
support parsing numeric git configs as bool
I'm not sure if git documents it aside from 0 and 1, but any integer
can be interpreted as a bool by it. Doing the same in git-annex is good
for consistency. Also, I am planning a config that starts out as a
numeric range, but will later transition to a simple bool (hopefully),
which this interpretation supports well.
Joey Hess [Fri, 13 Nov 2020 18:32:06 +0000 (14:32 -0400)]
rename to --unlock-present and better reverse adjusting
An --unlock-present branch reverses back to a branch where
all files that get modified or renamed become locked, even if they were
originally unlocked. This is the same that reversing a --unlock branch
works, and the new name makes that commonality more clear.