Renaming pages with attachments / subpages likely to fail on Windows
When renaming a page, where a file in the attachment directory (including subpages) is locked by a process, renaming will fail half-way, leaving the wiki in an inconsistent state.
Observed with Zim 0.63 and all prior versions I have used.
OS: Windows only (due to different handling of file handles).
In order to reproduce (Windows only)
1. create a page with subpages and attachments.
2. open one of the attachments in a program that acquires
exclusive file access, e.g. LibreOffice Calc.
3. Try to move/rename the page.
Renaming will fail with an error
The directory is not empty: P:\ATH\TO\DIRECTORY
and return to the renaming-dialog. Afterwards the contents of the renamed subtree will be spread wildly over both original name and new name (amongst others making repetition of the renaming impossible, as the page already exists), and links will not have been updated. Furthermore, re-indexing is required before the new name even appears in the tree pane.
The origin is Windows' different use of file locks. On Windows, you cannot rename or delete a file **or even its parent directories** while a process holds an open file handle (it seems that file handles are bound to the path here).
While there is no way to solve this basic problem, trying to rename the directory before doing anything else might help. Assuming that none of ZIM's txt files are locked, which shouldn't usually occur, all other operations should work.
For full safety, a journalling approach to wiki operations would be required (i.e. compiling a list of refactoring operations before trying any of them, hence providing means to resume refactoring after removing the file-lock). Unlike the "rename directories first" idea though, this would likely require prohibitive coding effort for little gain.