Re: [PATCH] Reduce the lifetime of open files within core FSFS7 routines

> NOTE: It looks like FSX suffers from the same kind of problem. There are 77
> failing tests from the standalone suite (client-test.exe, fs-test.exe, ...) and
> any attempt to run the Python tests (basic_tests.py, ...) immediately fails
> during the greek tree initialization phase. I guess I might be able to come up
> with a patch for this problem in the nearby future (in case someone does not
> fix it earlier):
>
> [[[
> (client-test.exe --fs-type=fsx)
>
> svn_tests: E720145: Can't remove directory
> 'BUILDPATH\subversion\tests\cmdline\svn-test-work\libsvn_client\
> test-wc-add-repos\db\transactions\0-0.txn': The directory is not empty.
> FAIL: client-test.exe 3: test svn_wc_add3 scenarios
>
> (win-tests.py --fs-type=fsx --test=basic_tests.py --log-to-stdout)
>
> Testing Release configuration on local repository.
> START: basic_tests.py
> E: import did not succeed, while creating greek repos.
> E: The final line from 'svn import' was:
> E: Can't remove directory
> 'BUILDPATH\subversion\tests\cmdline\svn-test-work\local-tmp\
> repos\db\transactions\0-0.txn': The directory is not empty.
> ]]]

Here is the promised patch.

Again, I've dumped CreateFile / CloseFile events for one of the failing tests
and tracked down the origin of the leaking file handles. It turns out that
svn_fs_x__p2l_index_create and svn_fs_x__l2p_index_create functions do
not close the PROTO_INDEX file when they are done working with it:
[[[
  svn_io_file_open + 0x1a, libsvn_subr\io.c(3423)
  svn_fs_x__l2p_index_create + 0xdc, libsvn_fs_x\index.c(694)
  commit_body + 0x4b0, libsvn_fs_x\transaction.c(3217)
  with_some_lock_file + 0xc0, libsvn_fs_x\transaction.c(249)
  svn_fs_x__with_write_lock + 0x6a, libsvn_fs_x\transaction.c(266)
  svn_fs_x__commit + 0x7e, libsvn_fs_x\transaction.c(3316)
  svn_fs_x__commit_txn + 0x145, libsvn_fs_x\tree.c(2198)
  svn_fs_commit_txn + 0x38, libsvn_fs\fs-loader.c(828)
]]]

As a consequence, purging a transaction on Windows ends with an ENOTEMPTY
error. This happens due to an attempt to remove a folder while still having
open file handles to some of its children and renders the FSX backend quite
unusable.

Thanks and regards,
Evgeny Kotkov