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 <tortoise...@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 | >>>> APR_FINFO_LINK); >>>> +#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 >
