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;
>>> flags = resolve_symlinks ? APR_FINFO_MIN : (APR_FINFO_MIN |
>>> 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
> 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
>> Making .svn a symbolic link on Linux came up in another thread recently:
>> 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
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.
> 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.
Received on 2018-06-08 00:31:40 CEST