kotkov in subversion

* subversion/libsvn_fs_fs/fs.c

(fs_ioctl): Tweak the code to have a single final statement returning


* subversion/libsvn_fs_fs/fs.c

(fs_ioctl): Minor refactoring. Explicitly return after handling an ioctl

in every else-if branch, instead of potentially falling through.

Adjust lifetime of the result returned from svn_repos__normalize_prop().

Previously, this function would make an unconditional copy of the value into

the result pool. While this may look convenient in some of the cases, there

is a downside of making unnecessary copies even if no normalization happened.

Instead of that, let's give the calling site control over the results' lifetime

by not making the copy if the input did not change. The callers may still dup()

the value if they need to, but with this approach there are no unavoidable

copies in various situations, such as where we would like to only update the

value if it changed or where we don't have an appropriate scratch pool, but

need to normalize the property value anyway.

* subversion/include/private/svn_repos_private.h

(svn_repos__normalize_prop): Adjust documentation.

* subversion/libsvn_repos/fs-wrap.c

(svn_repos__normalize_prop): Do not duplicate the input if no normalization

is required.

* subversion/libsvn_repos/dump_editor.c

(normalize_props): Adjust call to svn_repos__normalize_prop(), explicitly

duplicate the property value into the result pool.

* subversion/svnrdump/load_editor.c

(set_revision_property, set_node_property): Explicitly duplicate the property

values into the long-living pool.

* subversion/svnrdump/util.c

(svn_rdump__normalize_props): Adjust call to svn_repos__normalize_prop(),

explicitly duplicate the property value into the result pool.

Normalize line endings in node properties (such as svn:ignore) when loading

dumps with `svnadmin load --normalize-props`.

Previously, this command would only normalize revision properties, but

do nothing for node properties.

The problem has been reported by a user in the following thread:

* subversion/libsvn_repos/load-fs-vtable.c

(change_node_prop): Accept the new `normalize_props` argument, call

svn_repos__normalize_prop() for the property if it is set.

(set_node_property, delete_node_property, remove_node_props):

Update calling sites of the change_node_prop() function, pass the

stored `normalize_props` state of the parser.

* subversion/tests/cmdline/

(load_normalize_node_props): New regression test.

(test_list): Add new test.

* subversion/libsvn_repos/load-fs-vtable.c

(change_rev_prop): Document the `normalize_props` argument.

No functional changes.

Make the dump stream parser more resilient to malformed dump streams that

do not contain \n characters at all.

Previously, we'd attempt to load the whole input into memory due to how

svn_stream_readline() is currently implemented. Doing so could potentially

choke for large files. The corresponding real-world case is where a user

(accidentally) attempts to load a huge binary file that does not contain \n

characters as the repository dump.

This is the potential cause of the OOM reported in

* subversion/libsvn_repos/load.c

(parse_format_version): Read the dump version string directly from

stream, with an upper limit of 80 bytes. Comment on why we don't use

svn_stream_readline() for this particular case.

(svn_repos_parse_dumpstream3): Update the call to parse_format_version().

Fix an issue with the readline implementation for file streams that could

cause excessive memory usage for inputs containing one or multiple \0 bytes.

This is the likely cause of the OOM reported in

(I think that the problem itself is a regression introduced by me in 1.10.)

Note: one thing I noticed while preparing the fix is that our `readline_fn`

functions for different streams have inconsistent behavior if the input data

contains \0 bytes. More specifically, they may return different `line` values,

that may either be truncated at \0 or actually contain the whole data between

EOLs, including \0 bytes. For now, this patch only fixes the excessive memory

usage problem, and I noted this related problem in the test and left it for

future work.

* subversion/libsvn_subr/stream.c

(readline_apr_lf, readline_apr_generic): Reallocate the buffer based on its

current size, instead of calculating the new size based on the already

prealloc'd size. There are no actual benefits in reallocating based on

`blocksize`, and in the described case with \0 bytes doing so also backfires

and may cause excessive allocations due to the actual size of the string

being less than we expect it to. A degenerate case of the erroneous

behavior is ...

* subversion/tests/libsvn_subr/stream-test.c

(test_stream_readline_file_nul): ...exploited in this new test.

(test_funcs): Run new test.

* subversion/tests/libsvn_subr

(): Adjust svn:ignore.

When compiling SQLite, enable the SQLITE_OMIT_WAL compile-time option.

We don't use WAL (write-ahead logging) feature of SQLite, but just keeping it

enabled has a visible I/O performance penalty, because SQLite has to check if

the write-ahead log file is present on disk. In a couple of my experiments,

disabling this feature resulted in a ~10% faster `svn st` on a large working


* subversion/libsvn_subr/sqlite3wrapper.c


When compiling SQLite, set the SQLITE_DEFAULT_MEMSTATUS=0 compile-time option.

This is the recommended option that is not enabled by default. Setting it to

zero avoids using a mutex (and thus suffering a performance penalty) during

every sqlite3_malloc() call, where this mutex is used to properly update the

allocations stats. We don't use sqlite3_status(), so set this option to zero.


* subversion/libsvn_subr/sqlite3wrapper.c


Win32: fix an incorrect error status being propagated to the caller in case

where we fail to stat the destination path while being in the middle of a

failed rename.

So, if we fail to stat the destination in the middle of such rename, propagate

the *original* error. Because overriding the original error with the new one

loses information about the actual cause of failure and may even confuse some

of the callers, who for instance attempt to recover in case of an EACCES,

since they may not be receiving that error at all.

(This is the behavior we had for a long time, even before r1865518, but now

seems to be an appropriate moment to fix that)

* subversion/libsvn_subr/io.c

(win32_file_rename): Use a separate `stat_err` for the case of the failed

GetFileAttributes() call. If we failed to stat the file, return the

original `err` status to the caller.

* subversion/libsvn_subr/io.c

(win32_file_rename): Rename `status` to `err`. This lays the groundwork for

fixing the incorrect error status being propagated to the caller in case

where we fail to stat the destination path while being in the middle of

a failed rename.

Win32: prevent svn_io_file_rename2() from spinning in the retry loop in a

racy case where the rename function clears the read-only attribute from the

destination file, but another thread or process is quick enough to set it

back before the original rename function has a chance to proceed.

Despite sounding like an uncommon case, this may happen when the API is

being used to atomically update the file contents while also altering its

read-only attribute (and where such updates can occur in parallel).

Fix this by including the call that clears the read-only attribute on the

destination into the retry loop instead of calling it only once before


* subversion/libsvn_subr/io.c

(win32_file_rename): Handle EACCES/EEXIST and attempt to clear the

destination read-only attribute if it's there.

(svn_io_file_rename2): Don't call svn_io_set_file_read_write() in the

Win32-specific portion of this function, since clearing the read-only

attribute is now a part of the win32_file_rename() function.

Win32: tweak the SSL certificate validation override to avoid hitting the wire

for URL based objects and revocation checks.

The primary purpose of this callback is to resolve SVN_AUTH_SSL_UNKNOWNCA

failures using CryptoAPI and Windows local certificate stores. To do so, we

should be fine with just using the immediately available data on the local


Doing the opposite of that appears to be troublesome, as always connecting

to remote CRL and OCSP endpoints can result in spurious errors or significant

(user-reported) network stalls caused by timeouts if the endpoints are

inaccessible or unreliable.

The new approach should also be in par with the default basic behavior of

several major browsers, for example:

* subversion/libsvn_subr/win32_crypto.c

(windows_validate_certificate): Use the CERT_CHAIN_CACHE_ONLY_URL_RETRIEVAL

and CERT_CHAIN_REVOCATION_CHECK_CACHE_ONLY flags when preparing the

certificate chain. Ignore errors in obtaining valid revocation information

when verifying the chain, as they could be induced by the new cache-only


* STATUS: Propose r1859732, r1859734 for backport to 1.12.x (

io: Implement the functions that check for node existence using

the native Win32 APIs on Windows).

* subversion/libsvn_subr/io.c

(io_win_check_path): Tweak comment, no functional changes.

io: Implement the functions that check for node existence using the native

Win32 APIs on Windows:




This changeset aims for two distinct things:

1) First of all, starting from r1833621, these functions were patched to stop

checking symlinks on Windows. The root cause for this change has been an

incorrect implementation of stat in APR that didn't properly distinguish

between various types of reparse points, some of which are not symlinks.

Providing the custom implementation allows us to remove the hack and

properly handle such reparse points irrespectively of the APR version

in use.

Additional details on the core of the issue can be found here:



2) These APIs are used in various performance-critical code paths such as

in the core part of `svn st`.

On Win32 the necessary answers for these particular functions can be

obtained with a single call to GetFileAttributes(), which is much faster

than using the generic stat implementations from APR 1.6.x and 1.7.x

(I believe that it would be even slower in the latter case).

A couple of quick tests show about 20%-25% improvement in the speed of

`svn st` for a large working copy. The improvement may be more significant

with indexers or virus scanners, as just asking for file attributes may

completely avoid opening a file (by retrieving the result through the

fast I/O QueryOpen).

* subversion/libsvn_subr/io.c

(FILE_ATTRIBUTE_TAG_INFO, FileAttributeTagInfo): Add these definitions

for old versions of Windows SDK.

(typedef GetFileInformationByHandleEx_t,

get_file_information_by_handle_ex_proc): New.

(win_init_dynamic_imports): Import `GetFileInformationByHandleEx()`.

(win32_get_file_information_by_handle): New helper function.

(io_win_check_path): New helper with the Win32 implementation required

for the "check path" functions.



svn_io_check_special_path): Invoke the new helper.

(io_check_path): Undo the workaround from r1833621 that stopped passing

APR_FINFO_LINK when performing a stat.

* publish/download.html

(#pre-releases): Fix broken markup that was causing comments to

be rendered on the page.

Reimplement fsfs private operations required by `svnfsfs` (stats, dump index,

load index) as "ioctls".

Technically we achieve this by introducing the new svn_fs_ioctl() API that

adds a generic way of performing backend-specific I/O operations.

This change serves two purposes:

- It allows us to properly expose FS-specific details and invoke FS-specific

operations everywhere without necessarily promoting them into a proper

public API (the ioctl code itself may be made either public or private,

depending on the requirements).

- It solves a potential dependency/linking problem where tools like `svnfsfs`

work through the libsvn_fs's loader, but also have to load and call private

APIs from libsvn_fs_fs thus ignoring the loader. The latter part may

potentially cause issues with the global shared state, etc. With the

patch, all such operations always go through the FS loader.

* subversion/include/svn_fs.h

(svn_fs_ioctl, SVN_FS_DECLARE_IOCTL_CODE, svn_fs_ioctl_code_t): New.

* subversion/include/svn_error_codes.h


* subversion/include/private/svn_fs_fs_private.h

(svn_fs_fs__get_stats, svn_fs_fs__dump_index, svn_fs_fs__load_index):

These functions are now implemented as...


SVN_FS_FS__IOCTL_LOAD_INDEX): ...these new ioctls, which ...

(svn_fs_fs__ioctl_get_stats_input_t, svn_fs_fs__ioctl_get_stats_output_t,

svn_fs_fs__ioctl_dump_index_input_t, svn_fs_fs__ioctl_load_index_input_t):

...use these new structures.

* subversion/libsvn_fs/fs-loader.h

(fs_library_vtable_t.ioctl, fs_vtable_t.ioctl): New vtable members.

* subversion/libsvn_fs/fs-loader.c

(svn_fs_ioctl): Implement the new API by forwarding it to an appropriate

vtable member.

* subversion/libsvn_fs_fs/fs_fs.h

(svn_fs_fs__get_stats, svn_fs_fs__dump_index, svn_fs_fs__load_index):

These functions are now declared here.

* subversion/libsvn_fs_fs/fs.c

(): Include `svn_fs_fs_private.h`.

(fs_ioctl): Implement the ioctl dispatcher for three current fsfs-specific


(fs_vtable): Initialize the `ioctl` field.

(library_vtable): Initialize the `ioctl` field to NULL.

* subversion/libsvn_fs_fs/dump-index.c,



(): Tweak includes.

* subversion/libsvn_fs_base/fs.c

(library_vtable, fs_vtable): Initialize the `ioctl` field to NULL.

* subversion/libsvn_fs_x/fs.c

(library_vtable, fs_vtable): Initialize the `ioctl` field to NULL.

* subversion/svnfsfs/dump-index-cmd.c

(dump_index): Invoke an appropriate svn_fs_ioctl().

* subversion/svnfsfs/load-index-cmd.c

(load_index): Invoke an appropriate svn_fs_ioctl().

* subversion/svnfsfs/stats-cmd.c

(subcommand__stats): Invoke an appropriate svn_fs_ioctl().

* subversion/tests/libsvn_fs/fs-test.c

(test_unrecognized_ioctl): New test.

(test_funcs): Run the new test.

* subversion/tests/libsvn_fs_fs/fs-fs-private-test.c

(get_repo_stats, dump_index, load_index): Switch to svn_fs_ioctl().

* build.conf

(svnfsfs, fs-fs-private-test): Don't link to libsvn_fs_fs.

  1. … 3 more files in changeset.
Following up on r1847572, trace the errors constructed with the new helper.

* subversion/libsvn_fs_fs/tree.c

(open_path): Wrap the err_not_directory() return values with


Suggested by: brane

fsfs: Fix SVN-4791, an issue with the DAG open_path() that was causing

unexpected SVN_ERR_FS_NOT_DIRECTORY errors when attempting to open a path

with `open_path_node_only | open_path_allow_null` flags.

The implication of this is that certain svn_fs_closest_copy() calls could be

returing unexpected errors as well. For the end user, this means that such

errors were possible, for example, during certain `svn update`s.

The root cause of this behavior is the implementation of the optimization

within the open_path() routine. The optimization attempts to do a cache

lookup of the prospective parent directory of the path to be opened.

If the cache lookup is successful, the parent node is assumed — but not

checked — to be a directory. The absense of the check was causing

unexpected errors instead of returning `NULL` in a case where:

- open_path() is called with `open_path_node_only | open_path_allow_null`

- the path to be opened points to a non-existing path, but its parent path

is a file

- the DAG node of the "parent" file is cached


* subversion/libsvn_fs_fs/tree.c

(err_not_directory): New helper function factored out from...

(open_path): Check the kind of the DAG node for the prospective

parent returned from cache in the `open_path_node_only` optimization.

Handle the case where it is not a directory; utilize the new helper to

construct the appropriate error.

* subversion/tests/libsvn_fs/fs-test.c

(test_closest_copy_file_replaced_with_dir): New regression test.

(test_funcs): Run new test.

Following up on r1836306, provide an alternative fix for allowing things

like "svn commit -F <(echo foo)" that doesn't require a more expensive

apr_file_info_get(APR_FINFO_SIZE | APR_FINFO_TYPE) syscall in the

low-level and commonly used function.

Instead of additionally blacklisting APR_PIPE handles, rework the code to

work under the conditions where `finfo.size` may be wrong. That is, try to

read one more byte than necessary, expect to see an EOF, but if we don't

(e.g., for pipes), fall through to reading the remaining part of the file


This approach should work correctly under all possible cases where `finfo.

size` is incorrect, and also allows to just ask for APR_FINFO_SIZE, which

is generally cheaper. At least on Windows, this uses GetFileSizeEx() and

results in a single syscall.

* subversion/libsvn_subr/io.c

(stringbuf_from_aprfile): Replace the additional blacklist condition for

APR_PIPEs with the approach described above.

Add failing test for issue #4739, "Accept incoming deletion" option doing

nothing for a locally deleted file in the tree conflict resolver.

* subversion/tests/libsvn_client/conflicts-test.c

(test_update_incoming_delete_locally_deleted_file): New.

(test_funcs): Run new test.

* publish/docs/release-notes/1.10.html:

Merge the outstanding changes from 'staging'. The shortlog of the merged

changes is:

r1825983: Tweak the "FSFS f8 is new" bits in the intro.

r1825981: (#lz4-over-the-wire): Document current behaviour over ra_svn.

r1825980: Fix syntax error.

r1825871: (LZ4 compression over the wire in http:// and svn:// connections):

Try a more compact variant of the table that doesn't have the "compression"

word in every cell.

* publish/docs/release-notes/1.10.html

(Client-Server Protocol Changes): Comment this (currently) incomplete

section out, to avoid showing a work-in-progress documentation to the


* publish/docs/release-notes/1.10.html

(Compatibility Concerns, LZ4 compression): Remove pre-release compatibility

warnings, given that Subversion 1.10 is now GA.

* STATUS: Nominate r1826747.

Fix an issue in the svn_txdelta_to_svndiff_stream() API that could cause

unexpected short reads (EOFs) on the stream.

This API is used when performing PUT requests to the server. Consequently,

the bug could result in truncated payload being sent to the server and

failing commits over http://.

* subversion/libsvn_delta/svndiff.c

(svndiff_stream_read_fn): Handle a case where we have received the final

window from the txdelta stream, but the remaining part of the buffer

cannot fully accommodate it during this call to read_fn. Instead of

exiting and triggering an unexpected short read, allow the remaining

part to be read during subsequent calls to read_fn.

* subversion/tests/libsvn_delta

(): Add 'svndiff-stream-test' to svn:ignore.

* subversion/tests/libsvn_delta/svndiff-stream-test.c: New file with a

regression test for this issue.

* build.conf

(svndiff-stream-test): New.

(__ALL_TESTS__): Run svndiff-stream-test.

* docs/release-notes/1.10.html

(LZ4 compression over the wire in http:// and svn:// connections):

Try a more compact variant of the table that doesn't have the "compression"

word in every cell. In other words, turn "No compression", "LZ4 compression"

and "zlib compression" into "None", "LZ4" and "zlib" respectively.

* docs/release-notes/1.10.html

(Configuring the repository to use LZ4 compression): Fix section link.

Extend the 1.10 release notes with a subsection about using LZ4 compression

over the wire. For now, only document the negotiation and choice of the

compression algorithm for http://, and leave a TODO about svn://.

* docs/release-notes/1.10.html

(LZ4 compression): Extend the opener with the information that LZ4

compression is supported for both http:// and svn://.

(LZ4 compression over the wire in http:// and svn:// connections):

New subsection.

(New Feature Compatibility Table): Link to the new subsection.