WIth 0.8 just out the door, I began thinking about 0.9.
That version will focus on fixing Greyhole’s greatest bug creator: the rename operation!
There has been, and probably always will be, problems with the current implementation that Greyhole has to handle file and directory renames.
I have some ideas on how to fix them all, once and for all, but this will require some non-trial development, clean up and regression testing.
I’m hopeful that re-implementing this part of Greyhole will make it much less bug-prone, when renames are concerned.
More about this soon (when 0.9 will be released I guess…)
[...] Greyhole new website Greyhole Roadmap – version 0.9 [...]
What do you mean with rename bug? When does bugs appear with the rename operation? Especially in which situations?
When you rename already renamed or deleted files or directories, before GH can process the previous operation(s).
Example of a recently fixed bug:
mkdir dir1
echo 'a' > dir1/file1
# Wait for GH to process the above
mv dir1 dir2
mv dir2/file1 dir2/file2
mv dir2/file2 file2
# The last 3 operations needs to happen on the share before GH can start processing the first mv.
End result: the file ends up in the attic, instead of ending up as file2.
This is only an example. There are countless other cases that GH needs to be able to correctly handle.
I’m still working on creating test cases. But v0.8.4 contains all the fixes I made in light of the findings I made with the current test cases.
(i.e. there are no known issues at the moment, but I’m pretty positive there are still issues that have yet to be identified and fixed.)