Re: BUG: Delete svn:special property on symlink; hilarity ensues.

Daniel Shahaf <d.s_at_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
Received on 2018-08-31 21:10:42 CEST