[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: handling of reparse points

From: Branko Čibej <brane_at_apache.org>
Date: Fri, 8 Jun 2018 00:30:58 +0200

On 08.06.2018 00:30, Branko Čibej wrote:
> On 07.06.2018 18:50, Stefan Kueng wrote:
>> On 05.06.2018 23:35, Philip Martin wrote:
>>> Stefan Küng <tortoisesvn_at_gmail.com> writes:
>>>> Index: subversion/libsvn_subr/io.c
>>>> ===================================================================
>>>> --- subversion/libsvn_subr/io.c    (revision 1831874)
>>>> +++ subversion/libsvn_subr/io.c    (working copy)
>>>> @@ -342,8 +342,11 @@
>>>>     /* Not using svn_io_stat() here because we want to check the
>>>>        apr_err return explicitly. */
>>>>     SVN_ERR(cstring_from_utf8(&path_apr, path, pool));
>>>> -
>>>> +#ifdef WIN32
>>>> +  flags = APR_FINFO_MIN;
>>>> +#else
>>>>     flags = resolve_symlinks ? APR_FINFO_MIN : (APR_FINFO_MIN |
>>>> +#endif
>>>>     apr_err = apr_stat(&finfo, path_apr, flags, pool);
>>>>       if (APR_STATUS_IS_ENOENT(apr_err))
>>> This needs a comment to explain why Windows needs to do something
>>> different.
>> patch with comment attached.
>>> I think we would have to back this change out if we ever attempted to
>>> add svn:special support on Windows, but I suppose any such support is
>>> unlikely in the near future; as Branko pointed out CreateSymbolicLink
>>> doesn't have the semantics we want.
>> Just FYI: in that case svn would have a requirement for NTFS. Because
>> both hard links (for files) and junctions (for directories) only work
>> on NTFS. So it wouldn't be possible anymore to use svn on e.g. a usb
>> stick formatted with FAT32.
> Yes ... we'd _also_ have to detect the capabilities of the underlying
> filesystem.
>>> Making .svn a symbolic link on Linux came up in another thread recently:
>>> https://lists.apache.org/thread.html/d08f3a0b71600e2b67cd39817cd99e4de25a7e4f12817fe451f162e5@%3Cdev.subversion.apache.org%3E
>>> At present there is an assumption that .svn lives on the same filesystem
>>> as the working copy and that files can be atomically moved from .svn/tmp
>>> into the working copy (see workqueue.c calling svn_io_file_rename2).  If
>>> .svn becomes a symlink that points to a different filesystem then these
>>> moves fail and Subversion doesn't work.  We might be able to work around
>>> this by replacing svn_io_file_rename2 with svn_io_file_move.
>>> I don't know if Windows has the same problem.
>> On Windows, the MoveFileEx() API which is used by win32_file_rename
>> which is used by svn_io_file_rename2 can work that way: the flag
>> MOVEFILE_COPY_ALLOWED must be passed as well. Then the Move works
>> across volumes because Windows then does the move as a copy/delete
>> instead.
> We do use that flag, but — just like cross-device copies on Unix — the
> move is no longer atomic, which could break the working copy quite badly.

I mean cross-device moves, of course, not copies.

>> Also: the current implementation on Windows handles links wrong: it
>> assumes that a reparse point is always a junction, but that's not the
>> case. A junction is just a special form of a reparse point.
> Well, the more patches we get to fix these issues, the better.
> -- Brane
Received on 2018-06-08 00:32:23 CEST

This is an archived mail posted to the Subversion Dev mailing list.