If someone uploads a file that starts or ends with the chars {}, all REPORT requests on that collection will fail and it's impossible to delete the file.
On Windows 1/2 would be a safe filesystem path component, but it's not safe to pass it to path_to_filesystem.
Currently only the get method can be called with a href like that and it checked for that.
This just moves the check into the is_safe_filesystem_path_component function.
I don't think that this can be used for optimizations.
It's useless in the filesystem backend, SQL has REPLACE and I doubt that there is much use in any other storage mechanism.
vobject uses \r\n as line endings. Writing this to a file is not a problem on Linux and newer versions of MacOS. On Windows \r\r\n gets written to disk and on older versions of MacOS \r\r gets written to disk, because python replaces \n by the system depended line ending.
Close the lock file, when no more clients are waiting.
This option is not very useful in general, but on Windows files that are opened cannot be deleted. This causes tests to fail, because the deletion of the temporary filesystem folder fails.
Remove all etags that are directly calculated from data that's read from files.
1. They are not used anywhere (luckily).
2. Etags that are send to clients are calculated from the output of vobject's serialize method. If files are edited externally and vobject normalizes them (like wrapping long lines or replacing all line endings by \r\n), the etags that are sent to the client and the etags that are calculated from raw data will never match. If a new version of vobject is released and the formatting changes slightly, the checks will also always fail.
Disabling syncing increases the risk of data loss when the system crashes or power fails. On the positive it can increase the performance to a great extent.
Unfortunately the library doesn't support disabling of disk syncing, fortunately we only need a small subset of it's functionality which is easy to implement.
