On Wed, Jan 21, 2009 at 01:28:01AM +0100, Johannes Schindelin wrote: > Actually, I test first if it is there, and only if it is not, try to > create the symlink. > > Now, there is still a very minor chance for a race, namely if two > processes happen to test the existence of the missing symlink at exactly > the same time, and both do not find it, so both processes will try to > create it. Yep. Though I find "minor chance" when it comes to races to really mean "annoying to debug". But... > However, the symlink creation is not checked for success, so the processes > will still both run just fine. Yes, so there is no race in what is there currently. It's just sad that we can't detect any actual errors. > There is a very subtle problem, though. If you screw with your > configuration, replacing a link in t/valgrind/ by a script, my code will > not try to undo it. However, I think that's really asking for trouble, > and you can get out of the mess by "rm -r t/valgrind/git*". I think we can safely ignore such mucking about in the valgrind directory as craziness. > Another problem which is potentially much more troublesome is this: > when there was a script by a certain name, my code would symlink it > to $GIT_DIR/$BASENAME (actually a relative path, but you get the > idea). If that script is turned into a builtin -- this list has certainly > known a certain person to push for that kind of conversion :-) -- that > fact is not picked up. Yes. One way around this is to generate a "want" and a "have" list, and then just operate on the differences. Something like (totally untested): (cd $GIT_VALGRIND && ls) | sort >have (cd $TEST_DIRECTORY/.. && ls git git-*) | sort >want comm -23 have want | xargs -r rm -v comm -13 have want | while read f; do ln -s ../../$f $GIT_VALGRIND/$f; done and then you are also cleaning every time you create. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
