Renaming pages with attachments / subpages likely to fail on Windows

Bug #1474396 reported by K. Bauer on 2015-07-14
This bug affects 2 people
Affects Status Importance Assigned to Milestone

Bug Description

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.

Conor O'Neill (theyoungbard) wrote :

Similar story for me, only it won't start up again.

This is zim 0.63
Platform: nt
Locale: en_AU cp1252
FS encoding: mbcs
Python: (2, 7, 10, 'final', 0)
Gtk: (2, 24, 10)
Pygtk: (2, 24, 0)
Zim revision is:
  branch: trunk
  revision: 766 <email address hidden>
  date: 2015-06-14 11:19:01 +0200

======= Traceback =======
  File "zim\main.pyo", line 446, in main
  File "zim\main.pyo", line 211, in run
  File "zim\ipc.pyo", line 283, in start_server_if_not_running
AssertionError: Failed to start server (spawning)

tags: added: fs
Changed in zim:
status: New → Confirmed
importance: Undecided → Medium
tags: added: 2min

Latest version first moves the subtree, than the page itself, so more robust for this issue

Changed in zim:
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers