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. > 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
