Re: handling of reparse points
Branko Čibej writes: >> 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. svn_io_file_move() is our wrapper that is intended to make it work: it does a cross-device copy to a temporary name and then an atomic rename. That looks like it should be safe and workqueue.c:run_file_move() has a comment claiming this works. However there appears to be a different bug in svn_io_file_move: it doesn't delete the original after a successful cross-device copy/rename. It looks like r1685793 accidentally removed the delete. The cross-device code is old, it predates wc-ng, so it is possible that it is no longer exercised. For wc-ng it is not currently possible to put .svn or .svn/tmp on a separate device. -- Philip
Re: handling of reparse points
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 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(_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(, 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 >
Re: JavaHL crash on macOS 10.13.5
Thomas Singer writes: >> Thread 44 Crashed:: Java: WorkerThread-3 >> 0 libsystem_kernel.dylib 0x7fff696a0b6e __pthread_kill + 10 >> 1 libsystem_pthread.dylib 0x7fff6986b080 pthread_kill + 333 >> 2 libsystem_c.dylib0x7fff695fc1ae abort + 127 >> 3 libsvn_subr-1.0.dylib 0x00011ef564f5 abort_on_pool_failure + >> 4 libserf-1.dylib 0x00011f0dec53 serf__process_connection + 259 >> 5 libserf-1.dylib 0x00011f0dd263 serf_event_trigger + 163 >> 6 libserf-1.dylib 0x00011f0dd39c serf_context_run + 108 >> 7 libsvn_ra_serf-1.0.dylib 0x00011f394845 >> svn_ra_serf__context_run + 69 > Unfortunately, I neither can't reproduce the crash on our macOS 10.13 > machine nor do I understand the reason for the crash. Could it be, > somehow, be caused by us having compiled SVN incorrectly? Or could > this be a problem of libsystem_kernel.dylib, libsystem_pthread.dylib, > libsystem_c.dylib? Thanks in advance for any helpful clue. abort_on_pool_failure() indicates that the process failed to allocate dynamic memory. There could be a memory leak, causing the process to allocate an excessive amount of memory. There could be some limit on the process causing it to fail when attempting to allocate a large, but reasonable, amount of memory. Was the commit "large" in some way? Lots of files? Large files? Deep directories? Lots of properties? Large properties? etc. -- Philip
JavaHL crash on macOS 10.13.5
Hi experts, We've got a macOS crash report from a user of SmartSVN (that uses JavaHL for performing SVN commands). The following thread crashed when the user tried to add/commit a new file: Thread 44 Crashed:: Java: WorkerThread-3 0 libsystem_kernel.dylib 0x7fff696a0b6e __pthread_kill + 10 1 libsystem_pthread.dylib 0x7fff6986b080 pthread_kill + 333 2 libsystem_c.dylib 0x7fff695fc1ae abort + 127 3 libsvn_subr-1.0.dylib 0x00011ef564f5 abort_on_pool_failure + 21 4 libserf-1.dylib 0x00011f0dec53 serf__process_connection + 259 5 libserf-1.dylib 0x00011f0dd263 serf_event_trigger + 163 6 libserf-1.dylib 0x00011f0dd39c serf_context_run + 108 7 libsvn_ra_serf-1.0.dylib0x00011f394845 svn_ra_serf__context_run + 69 8 libsvn_ra_serf-1.0.dylib0x00011f394976 svn_ra_serf__context_run_wait + 86 9 libsvn_ra_serf-1.0.dylib0x00011f394a5a svn_ra_serf__context_run_one + 138 10 libsvn_ra_serf-1.0.dylib0x00011f3840ef close_file + 223 11 libsvn_wc-1.0.dylib 0x00011f4cccee svn_wc__internal_transmit_text_deltas + 1342 12 libsvn_wc-1.0.dylib 0x00011f4ccd43 svn_wc_transmit_text_deltas3 + 67 13 libsvn_client-1.0.dylib 0x00011f57a554 svn_client__do_commit + 596 14 libsvn_client-1.0.dylib 0x00011f579373 svn_client_commit6 + 3475 15 libsvnjavahl-1.dylib0x00011f5fbed2 SVNClient::commit(Targets&, CommitMessage*, svn_depth_t, bool, bool, StringArray&, PropertyTable&, CommitCallback*) + 242 16 libsvnjavahl-1.dylib0x00011f60e555 Java_org_apache_subversion_javahl_SVNClient_commit + 453 17 ??? 0x00010fe96a74 0 + 4561922676 18 ??? 0x00010fe87302 0 + 4561859330 19 ??? 0x00010fe87040 0 + 4561858624 20 ??? 0x00010fe87114 0 + 4561858836 21 ??? 0x00010fe87040 0 + 4561858624 22 ??? 0x00010fe87040 0 + 4561858624 23 ??? 0x00010fe872bd 0 + 4561859261 24 ??? 0x00010fe872bd 0 + 4561859261 25 ??? 0x00010fe87040 0 + 4561858624 26 ??? 0x00010fe87114 0 + 4561858836 27 ??? 0x00010fe87040 0 + 4561858624 28 ??? 0x00010fe87114 0 + 4561858836 29 ??? 0x00010fe87114 0 + 4561858836 30 ??? 0x00010fe87302 0 + 4561859330 31 ??? 0x00010fe872bd 0 + 4561859261 32 ??? 0x00010fe87302 0 + 4561859330 33 ??? 0x00010fe7f7a7 0 + 4561827751 34 libjvm.dylib0x000100b4870a JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 1710 35 libjvm.dylib0x000100b48eae JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*) + 356 36 libjvm.dylib0x000100b4905a JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Thread*) + 74 37 libjvm.dylib0x000100ba37b1 thread_entry(JavaThread*, Thread*) + 124 38 libjvm.dylib0x000100dc60b3 JavaThread::thread_main_inner() + 155 39 libjvm.dylib0x000100dc77a0 JavaThread::run() + 450 40 libjvm.dylib0x000100ce5aee java_start(Thread*) + 246 41 libsystem_pthread.dylib 0x7fff69868661 _pthread_body + 340 42 libsystem_pthread.dylib 0x7fff6986850d _pthread_start + 377 43 libsystem_pthread.dylib 0x7fff69867bf9 thread_start + 13 Unfortunately, I neither can't reproduce the crash on our macOS 10.13 machine nor do I understand the reason for the crash. Could it be, somehow, be caused by us having compiled SVN incorrectly? Or could this be a problem of libsystem_kernel.dylib, libsystem_pthread.dylib, libsystem_c.dylib? Thanks in advance for any helpful clue. -- Best regards, Thomas Singer
Re: Documentation to build SVN 1.10
Stefan Sperling-9 wrote > On Wed, Apr 18, 2018 at 10:50:15AM +0200, Thomas Singer wrote: >> Hi developers, >> >> I'm trying to build SVN 1.10 on CentOS 6.2 based on a black-box build >> script >> that I have for SVN 1.9. So far it looks like SVN 1.10 requires a newer >> sqlite-amalgamation-3081101.zip and requires something regarding LZ4. >> Unfortunately, simply adding "--with-lz4=internal" is not sufficient, >> because now it complains about "Subversion requires UTF8PROC". How to >> install that - where can I find documentation about how to build SVN >> 1.10? > > See ./configure --help ; utf8proc is another new required dependency > and, like with lz4, there's an internal copy you could compile with. It helped me to compile on Linux, Thank you for responce - Mobile App Development Company -- Sent from: http://subversion.1072662.n5.nabble.com/Subversion-Dev-f4725.html
