Definition of `bool file::has_manage_volume_privs` involves a call to
`get_manage_volume_privs()`, causing restricted tasks to be performed
from within `DllMain` function. They introduce possibility that client
application deadlocks or crashes.
You should never perform the following tasks from within DllMain:
* Call `LoadLibrary` or `LoadLibraryEx` (either directly or indirectly).
This can cause a deadlock or a crash.
* Call the registry functions. These functions are implemented in
'Advapi32.dll'. If not initialized before your DLL, it can access
uninitialized memory and cause the process to crash.
File locking interacts poorly with the path to replace a read only file handle
with a read/write one. For performance reasons the old handle is not closed
until the new one is put in place. With file locking this obviously cannot
work because the first handle is holding a lock on the file. As a result,
file_pool::open_file fails in this case. Even if we dropped the reference to
the read only file handle before attempting to re-open it, the open could still
fail if another thread is holding a reference to the read only handle.
There doesn't seem to be a good way around this. The simple solution would be
to always open files in read/write mode, but that has obvious safety downsides.
Any other solution would significantly complicate the file pool code.
Deprecating file locking seems to be the least bad option.
use unsigned type for file flags. make file_pool private to disk_io_thread. move close_file_interval logic to the disk thread. don't expose file in public interface, and make pool_file_status properly public (not part of file_pool and renamed to open_file_status), this is exposed in public interface via torrent_handle::file_status()
arvidn