Merge branch 'master' of /home/b-git-annex/source
This commit is contained in:
commit
d1fe9d0d2a
5 changed files with 47 additions and 1 deletions
|
@ -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.
|
||||
"""]]
|
|
@ -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.
|
||||
"""]]
|
|
@ -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.)
|
||||
"""]]
|
|
@ -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.
|
||||
"""]]
|
|
@ -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,
|
||||
|
|
Loading…
Reference in a new issue