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
|
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
|
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
|
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
|
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,
|
the pid of the process that a thread starts as belonging to the thread,
|
||||||
|
|
Loading…
Add table
Add a link
Reference in a new issue