diff options
Diffstat (limited to 'doc/bugs')
3 files changed, 4 insertions, 4 deletions
diff --git a/doc/bugs/__34__git-annex__58___direct__58___1_failed__34___on_Windows/comment_2_dfc398002e2ffbe0b63ce422a1e16d67._comment b/doc/bugs/__34__git-annex__58___direct__58___1_failed__34___on_Windows/comment_2_dfc398002e2ffbe0b63ce422a1e16d67._comment index 89af53b41..558a1ce23 100644 --- a/doc/bugs/__34__git-annex__58___direct__58___1_failed__34___on_Windows/comment_2_dfc398002e2ffbe0b63ce422a1e16d67._comment +++ b/doc/bugs/__34__git-annex__58___direct__58___1_failed__34___on_Windows/comment_2_dfc398002e2ffbe0b63ce422a1e16d67._comment @@ -21,5 +21,5 @@ The MSDN article has one very interesting bit: (It seems that, when using that prefix, `/` is not converted to `\` .. I think git-annex is quite good about getting the slashes the right way round these days.) -So it might be possible for git-annex to use that prefix and avoid this issue entirely. Haskell's FilePath library does understand that prefix (treats it as part of the drive). Since git-annex always uses the path to the top of the Repo when constructing the problimatic FilePaths, I might be able to just change the Repo constructor to add that prefix, and everything follow from that. I tried doing that, unfortunately this makes *git* fail, with \"fatal: relative path syntax cannot be used outside working tree\" when operating on such a repo. Cause git doesn't understand that prefix. +So it might be possible for git-annex to use that prefix and avoid this issue entirely. Haskell's FilePath library does understand that prefix (treats it as part of the drive). Since git-annex always uses the path to the top of the Repo when constructing the problematic FilePaths, I might be able to just change the Repo constructor to add that prefix, and everything follow from that. I tried doing that, unfortunately this makes *git* fail, with \"fatal: relative path syntax cannot be used outside working tree\" when operating on such a repo. Cause git doesn't understand that prefix. """]] diff --git a/doc/bugs/git-annex_doesn__39__t_work_on_lustre__58___waitToSetLock__58___unsupported_operation___40__Function_not_implemented__41__/comment_7_1c0352c37ff07a8478d13c12aa72b484._comment b/doc/bugs/git-annex_doesn__39__t_work_on_lustre__58___waitToSetLock__58___unsupported_operation___40__Function_not_implemented__41__/comment_7_1c0352c37ff07a8478d13c12aa72b484._comment index e0f73a82f..4d2916712 100644 --- a/doc/bugs/git-annex_doesn__39__t_work_on_lustre__58___waitToSetLock__58___unsupported_operation___40__Function_not_implemented__41__/comment_7_1c0352c37ff07a8478d13c12aa72b484._comment +++ b/doc/bugs/git-annex_doesn__39__t_work_on_lustre__58___waitToSetLock__58___unsupported_operation___40__Function_not_implemented__41__/comment_7_1c0352c37ff07a8478d13c12aa72b484._comment @@ -34,11 +34,11 @@ The only option on the git-annex side would be to add an option to totally disable use of locks, which would make it rather unsafe to use. Or to use only dotlocks (file existence level locks). -Dotlocks are problimatic. Some of the uses git-annex makes of locking, +Dotlocks are problematic. Some of the uses git-annex makes of locking, like using both shared and exclusive locks on a file to let multiple concurrent readers, would be very hard to emulate with dotlocks. Also, dotlocks go stale when processes die, and git-annex uses lots of different -locks in different places, which would be problimatic to clean up in such +locks in different places, which would be problematic to clean up in such a situation. I think that it might make sense, if git-annex has to fall back to dotlocks, diff --git a/doc/bugs/git-annex_merge_stalls/comment_3_ced9b0d724fb55c756106b64c3721003._comment b/doc/bugs/git-annex_merge_stalls/comment_3_ced9b0d724fb55c756106b64c3721003._comment index 382f8c835..a0f452b5d 100644 --- a/doc/bugs/git-annex_merge_stalls/comment_3_ced9b0d724fb55c756106b64c3721003._comment +++ b/doc/bugs/git-annex_merge_stalls/comment_3_ced9b0d724fb55c756106b64c3721003._comment @@ -11,7 +11,7 @@ joeyh so, my thought is that perhaps you had a git-annex process before that was joeyh for example, if you ran it and ctrl-z'd at just the right time, it could be suspended and holding the lock joeyh (or the kernel coud have gotten confused, which given you also had a crash, who knows..) dp sounds logical -joeyh forcing locks is always a problimatic thing +joeyh forcing locks is always a problematic thing joeyh but git-annex could certainly notice if it seems to be stalled and print some useful messages joeyh and maybe have a way to run with locks forced </pre> |