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.
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.
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.
Stefan
Index: libsvn_subr/io.c
===================================================================
--- libsvn_subr/io.c (revision 1833061)
+++ libsvn_subr/io.c (working copy)
@@ -342,8 +342,12 @@
/* 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
+ /* on Windows, svn does not handle reparse points or hard links */
+ 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))
