Daniel Shahaf <d...@daniel.shahaf.name> writes: >Karl, this part is entirely normal. > >When you do «echo bar > qux», your shell calls open(O_TRUNC), not >unlink(). In your case, since new-foo is a symlink on disk, when you do >«/some/command > new-foo», your shell calls open(O_TRUNC) on new-foo and >writes the command's output to it… and, according to the semantics of >symlinks, calling open(O_TRUNC) and write() on the symlink 'new-foo' is >equivalent to calling those syscalls on the symlink's target, ./foo. >This has nothing to do with svn and everything to do with shell syntax >(the use of 'svn cat' is a red herring).
Aaah, thank you. That makes perfect sense. I didn't realize that redirected output follows links that way -- somehow in all the years I've been Unix'ing that hasn't come before until now. (I thought ">" would behave similarly to "rm", since ">" also creates a file.) >> I looked in the bug tracker and >> https://issues.apache.org/jira/browse/SVN-2622 >> shows another way to reach the first (and less serious) of the two bugs >> demonstrated in the attached script. No other tickets seem to be related. >> > >That's "SVN-4622: Sym links can only be replaced in 2 steps", already fixed. Yup. SVN-2622, you mean -- the same issue I found. >This is exactly how one adds or edits a symlink on !HAVE_SYMLINK >platforms, including Windows. (You can get this behaviour on Unix if >you get configure to lie about the HAVE_SYMLINK test result.) I suppose >it's a public API therefore, although it's a bit odd that our >serialization format _is_ our public API; I'd have expected some sort of >layering decoupling the two. Well, I don't mind the part about our serialization format also being effectively our API for this. But the question is, what *should* the behavior be if one deletes the 'svn:special' property of a symlink? $ svn propdel svn:special some_version_controlled_symlink $ svn status -q ~M some_version_controlled_symlink $ svn commit -m "This commit will fail." svn: E145001: Commit failed (details follow): svn: E145001: Node '/.../some_version_controlled_symlink has \ unexpectedly changed kind $ The above doesn't seem right... I think my original proposal is a sane outcome, or is maybe the least insane outcome. But I'd like to know what others think. (This isn't exactly what #2622 was about, although perhaps under the hood the problems that led to #2622 are related to this problem.) Best regards, -Karl
