Re: handling of reparse points

On Sat, May 26, 2018 at 9:42 AM, Branko Čibej <brane_at_apache.org> wrote:
> On 25.05.2018 20:30, Stefan Kueng wrote:
>>
>>
>> On 25.05.2018 18:07, Daniel Shahaf wrote:
>>> Stefan Küng wrote on Fri, 25 May 2018 17:37 +0200:
>>>> Can anyone comment on this please?
>>>
>>> I'm not familiar with the Windows side of things, but I gave the
>>> patch a spin.
>>
>> And I'm not familiar with soft/hardlinks on Linux. :)
>>
>>> If I do 'mv .svn x; ln -s x .svn', things seem to work. However, if the
>>> target of the '.svn' symlink isn't in the same directory as the symlink,
>>> 'status' just shows everything with '!' status. I didn't check, but
>>> if I'd
>>> done 'ln -s ../../.svn subversion/tests/.svn' and run 'status' in
>>> subversion/tests/, I assume it would confuse trunk/README and
>>> trunk/subversion/tests/README (due to having the same basename).
>>
>> ok, so this breaks on non-Windows systems.
>> I'll try another patch soon.
>>
>> question: symlink handling in svn does not seem to actually work on
>> Windows. At least the docs state that they're not handled on Windows.
>> So why do we even check for 'special' nodes on a Windows build?
>>
>> If e.g. svn_io_check_special_path() on Windows would always return
>> false and svn_io_check_path() always call svn_io_check_resolved_path()
>> instead, this would work fine with the reparse points on Windows.
>>
>> So is there a reason why this is not done so on Windows? Is there
>> maybe a reason for handling reparse points specially on Windows that I
>> don't know of?
>
> Subversion can't create symbolic links on Windows the way it can on any
> normal OS, for several reasons:
>
> * The Windows CreateSymbolicLink function needs to know in advance if
> the target of a symlink (or any other kind of reparse point, really)
> is a directory or not. That's a non-starter; Unix symlinks can point
> to a non-existent target.
> * It requires elevated permissions on most versions of Windows.
> * Windows reparse points have subtly different semantics than symlinks
> on Unix.

I don't think that's what StefanK is after (versioning symlinks /
handling versioned symlinks on Windows). AFAIU Stefan is trying to
make SVN work properly on Windows when the entire working copy itself
(or maybe only its .svn folder?) is "tucked away" behind a reparse
point.

"It seems that svn doesn't handle reparse points properly in all
situations. Which causes big problems for TSVN when a working copy is
on a Onedrive folder. [...] I've attached a patch for handling reparse
points better when detecting and reading the working copy database."

Or maybe you were replying specifically to Stefan's points / questions
about svn_io_check_[special_|resolved_]path ? Does he actually need to
use another API (or write his own helper functions) for what he's
trying to do here?

(Just trying to clear up a possible source of confusion)

-- 
Johan