Re: JavaHL crash on macOS 10.13.5

2018-06-08 Thread Philip Martin
Thomas Singer  writes:

> For adding/committing an empty file he is getting:
>
>> $ touch testfile.txt
>> $ svn add testfile.txt A testfile.txt
>> $ svn commit -m "commit test" testfile.txt Adding testfile.txt
>> Transmitting file data .svn: E175002: Commit failed (details follow):
>> svn: E175002: Unexpected HTTP status 400 'Bad Request' on
>> '/svn/Projects/!svn/txr/7198-5vq/E867%20MS%20Marin/testfile.txt'

That's a server error, there should be more details in the Apache error
log.

>>> $ svn commit -m "commit test" Test\ Commit\ File.rtf Adding Test 
>>> Commit File.rtf
>>> Transmitting file data .libsvn: Out of memory - terminating application.
>>> Abort trap: 6
>>
>> Are there other, portable SVN binaries for macOS available to try
>> them, too? Maybe the problem is caused by how we build?

I don't know much about debugging on macOS.  Using dtruss to trace the
commit might provide some more information.

-- 
Philip


Re: handling of reparse points

2018-06-08 Thread Stefan Kueng




On 08.06.2018 00:30, Branko Čibej wrote:


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.


And not just that: you'd also have to check whether a reparse point is 
in fact a junction and not something else (like the sparse files of the 
OneDrive folder).



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.


there's also the MoveFileTransacted(), but MS recommends to not use that 
if there's another way to do it.



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.


In the mean time, can we apply my patch to make things work with 
OneDrive folders?


Stefan