diff options
8 files changed, 36 insertions, 1 deletions
diff --git a/doc/bugs/Android_:_handling_DCIM__47__Camera_not_being_configurable.mdwn b/doc/bugs/Android_:_handling_DCIM__47__Camera_not_being_configurable.mdwn index ee73cbeb6..a52857d1f 100644 --- a/doc/bugs/Android_:_handling_DCIM__47__Camera_not_being_configurable.mdwn +++ b/doc/bugs/Android_:_handling_DCIM__47__Camera_not_being_configurable.mdwn @@ -12,5 +12,5 @@ In the log, there are many "too many open files" errors like these : git:createProcess: runInteractiveProcess: pipe: resource exhausted (Too many open files) -[[!moreinfo]] +[[!tag moreinfo]] [[!meta title="too many open files on android"]] diff --git a/doc/bugs/Can__39__t_access_files_from___39__Removable_drive__39___repo_even_if_set_as_client.mdwn b/doc/bugs/Can__39__t_access_files_from___39__Removable_drive__39___repo_even_if_set_as_client.mdwn index ef59954b7..941ac9e5a 100644 --- a/doc/bugs/Can__39__t_access_files_from___39__Removable_drive__39___repo_even_if_set_as_client.mdwn +++ b/doc/bugs/Can__39__t_access_files_from___39__Removable_drive__39___repo_even_if_set_as_client.mdwn @@ -19,3 +19,4 @@ I'm using 9e57edff287ac53fc4b1cefef7271e9ed17f2285 (Fri Feb 22 15:19:25 2013 +00 Ubuntu 12.10 x86_64 [[!tag /design/assistant]] +[[!meta title="assistant should set up non-bare repos on removable drives, and update them when syncing with them"]] diff --git a/doc/bugs/Corrupted_drive:_Assistant_seems_consider_files_deleted_and_deletes_them_elsewhere_too.mdwn b/doc/bugs/Corrupted_drive:_Assistant_seems_consider_files_deleted_and_deletes_them_elsewhere_too.mdwn index de879f522..b6c9691ea 100644 --- a/doc/bugs/Corrupted_drive:_Assistant_seems_consider_files_deleted_and_deletes_them_elsewhere_too.mdwn +++ b/doc/bugs/Corrupted_drive:_Assistant_seems_consider_files_deleted_and_deletes_them_elsewhere_too.mdwn @@ -31,3 +31,6 @@ I noticed the problem yesterday afternoon (Thu 24 Oct). # End of transcript or log. """]] + +> [[moreinfo]]; either I don't have enough information to work on this, +> or it might have just been user error. --[[Joey]] diff --git a/doc/bugs/Disconcerting_warning_from_git-annex.mdwn b/doc/bugs/Disconcerting_warning_from_git-annex.mdwn index 169dc26d1..ef662441c 100644 --- a/doc/bugs/Disconcerting_warning_from_git-annex.mdwn +++ b/doc/bugs/Disconcerting_warning_from_git-annex.mdwn @@ -4,3 +4,5 @@ I did a "git annex add" of a bunch of files on a storage server with low IOPS, a failed How is that even possible, when the server is doing nothing else? + +[[!tag moreinfo]] diff --git a/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone..mdwn b/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone..mdwn index e01310336..0d442437d 100644 --- a/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone..mdwn +++ b/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone..mdwn @@ -228,3 +228,13 @@ Everything up-to-date """]] Well, I see that thing about "failed to lock". I can imagine that my 'killall git-annex' to kill a leftover process that was hanging around after I'd done git-annex assistant --stop might have left stale lock files, somewhere... but of course I only got as far as doing that because I was already encountering problems, just trying to return to the webapp. + +> The original bug report seems to be a case of user confusion, +> and not a bug. (Although perhaps the UI is confusing?) +> +> The "resource exhausted" that came up later is quite likely the problem +> fixed in [[!commit 4d06037fdd44ba38fcd4c118d1e6330f06e22366]], +> which affected local git remotes. +> +> [[closing|done]]; I don't see any value keeping this open, I'm afraid. +> --[[Joey]] diff --git a/doc/bugs/git_annex_sync_deleted_a_bunch_of_files___40__not_expected__41__.mdwn b/doc/bugs/git_annex_sync_deleted_a_bunch_of_files___40__not_expected__41__.mdwn index 2fb3d970b..619e8e5b8 100644 --- a/doc/bugs/git_annex_sync_deleted_a_bunch_of_files___40__not_expected__41__.mdwn +++ b/doc/bugs/git_annex_sync_deleted_a_bunch_of_files___40__not_expected__41__.mdwn @@ -38,3 +38,5 @@ upgrade supported from repository versions: 0 1 2 4 # End of transcript or log. """]] + +> [[closing|done]], not a bug based on the limited description. --[[Joey]] diff --git a/doc/bugs/whereis_claims_file_is_not_here__44___but_it_is_available_both_here_and_in_another_remote.mdwn b/doc/bugs/whereis_claims_file_is_not_here__44___but_it_is_available_both_here_and_in_another_remote.mdwn index ee69014d2..98ee21d16 100644 --- a/doc/bugs/whereis_claims_file_is_not_here__44___but_it_is_available_both_here_and_in_another_remote.mdwn +++ b/doc/bugs/whereis_claims_file_is_not_here__44___but_it_is_available_both_here_and_in_another_remote.mdwn @@ -26,3 +26,5 @@ lrwxrwxrwx 1 jkt jkt 329 Mar 3 02:08 2011-08-13 Svatba Anička Fellnerová a v The directory names are valid UTF-8. These are very common on my machine and there is a ton of directories with these funny names here -- all working without any real trouble. As far as I know, the file which the links point to is absolutely correct and not corrupted. Looking at the files in the directory chronologically, it also appears that the symlinks point to a correct file. + +[[!tag moreinfo]] diff --git a/doc/devblog/day_137-138__bug_triage_and_too_much_windows.mdwn b/doc/devblog/day_137-138__bug_triage_and_too_much_windows.mdwn new file mode 100644 index 000000000..feff2ba8a --- /dev/null +++ b/doc/devblog/day_137-138__bug_triage_and_too_much_windows.mdwn @@ -0,0 +1,15 @@ +Yesterday, worked on cleaning up the todo list. Fixed Windows slash problem +with rsync remotes. Today, more Windows work; it turns out to have been +quite buggy in its handling of non-ascii characters in filenames. Encoding +stuff is never easy for me, but I eventually managed to find a way to fix +that, although I think there are other filename encoding problems lurking +in git-annex on Windows still to be dealt with. + +Implemented an interesting metadata feature yesterday. It turns out that +metadata can have metadata. Particularly, it can be useful to know when a +field was last set. That was already beeing tracked, internally (to make +union merging work), so I was able to quite cheaply expose it as +"$field-lastchanged" metadata that can be used like any other metadata. + +I've been thinking about how to implement [[required_content]] expressions, +and think I have a reasonably good handle on it. |