mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

Merge branch 'master' of ssh://git-annex.branchable.com

Browse source
This commit is contained in:
Joey Hess 2013-12-31 16:39:50 -04:00
commit 8dbf230afe
8 changed files with 96 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

24
doc/bugs/Assistant_from_standalone_5.20131230_64bit_crashes_on_startup/comment_2_107ab23eac98a168d2920bb88b4ec86f._comment Normal file
View file

@ -0,0 +1,24 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.227"
subject="comment 2"
date="2013-12-31T19:11:16Z"
content="""
I've verified that git-annex runs the web browser in a cleaned up environment, that does not, for example, have the `LD_LIBRARY_PATH` used by the bundle set.
I checked this by making a ~/dumpenv script:
[[!format sh \"\"\"
#!/bin/sh
set
echo \"$@\"
\"\"\"]]
Then `chmod +x ~/dumpenv; git config web.browser ~/dumpenv` and `git annex webapp` to run it.
I did notice that it set `GCONV_PATH=''`, rather than unsetting that variable, and have made a commit fixing that. But I doubt that caused this problem.
The \"g_slice_set_config: assertion 'sys_page_size == 0\" seems to be a Mozilla bug: <https://bugzilla.mozilla.org/show_bug.cgi?id=672671>, and does not seem to be related, probably firefox is printing that well before crashing.
It looks like libc can somehow demand-load libgcc_s.so, so I have force included that into the bundle. Don't know if that will help. Will be available in autobuilds in an hour.
"""]]

12
doc/bugs/on_encfs__44___.fuse__95__hiddenXXXXX_files_left_behind/comment_1_b96ea3ece44d42e79e4d903ca66065ee._comment Normal file
View file

@ -0,0 +1,12 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.227"
subject="comment 1"
date="2013-12-31T19:35:20Z"
content="""
When git-annex is deleting an object's content, it opens the object, locks it, unlinks it, and closes it. This is necessary in order to avoid various race conditions that could cause data loss (ie, another repository might be in the process of verifying that the object that is being deleted is present).
I suspect that is what causes the problem with encfs. Since it is entirely a valid POSIX operation to do this, and since not doing it could cause data loss in some situations, I am very reluctant to change anything in git-annex in this area.
It's unfortunate that encfs seems to cause so many problems for POSIX filesystem semantics. Luckily, there are other ways to encrypt filesystems that do not suffer from such problems.
"""]]

8
doc/bugs/webapp_takes_100__37___of_the_cpu/comment_1_6312860de9f30cbb05762cd67edc705a._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.227"
subject="comment 1"
date="2013-12-31T19:38:24Z"
content="""
The webapp pushes a changed html div to the browser when eg, updating the progress bar. This is inneficient, which doesn't usually matter, since git-annex is not generally used with a large number of small files
"""]]