Merge branch 'master' of /home/b-git-annex/source

This commit is contained in:
admin 2020-02-20 20:48:37 +00:00
commit d1fe9d0d2a
5 changed files with 47 additions and 1 deletions

View file

@ -0,0 +1,9 @@
[[!comment format=mdwn
username="joey"
subject="""re: comment 4"""
date="2020-02-20T19:30:38Z"
content="""
With approptiate locking to prevent concurrency problems. As is the case
extensively throughout git-annex, although users seem to keep expecting
that to not be the case no matter how many times I assure them it is.
"""]]

View file

@ -0,0 +1,9 @@
[[!comment format=mdwn
username="joey"
subject="""Re: representing unlocked state of files"""
date="2020-02-20T20:23:41Z"
content="""
Starting with "/annex/objects" is not enough, the remainder of
the first line of the file has to parse as a git-annex key
for it to be a pointer file.
"""]]

View file

@ -0,0 +1,16 @@
[[!comment format=mdwn
username="joey"
subject="""comment 2"""
date="2020-02-20T20:12:24Z"
content="""
Like git, git-annex tries to be character set agnostic when it comes to
filenames, including key filenames.
It's certianly possible for a key to contain non-ascii bytes in its name,
and an extension containing unicode or some other non-ascii value is one
way that can in fact happen.
(Looks like, in a C locale, ".extü" is 5 chars long, so is considered too
long to be an extension, while in a unicode locale, it's 4 chars long, so
is treated as an extension.)
"""]]

View file

@ -0,0 +1,11 @@
[[!comment format=mdwn
username="joey"
subject="""comment 4"""
date="2020-02-20T20:29:20Z"
content="""
If you have a problem with some change that was made to fix a security
hole, about the only thing you can do is file a bug report. With some
really well thought out way to improve it ideally. I'm certianly not going
to revert security hole fixes because some comment here complains about
them.
"""]]

View file

@ -53,7 +53,8 @@ different types of processes a remote might run.
while it's being used, and then gets put back into the pool once
it's idle again. So, register the pid as belonging to a thread when
the thread removes it from the pool, and deregister it when the thread
returns it.
returns it. If the thread gets killed, don't add it back to the pool,
but instead kill the process.
3. All the rest. For these what's needed is some way to register
the pid of the process that a thread starts as belonging to the thread,