Zim

Renaming pages with attachments / subpages likely to fail on Windows

Bug #1474396 reported by K. Bauer
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Zim
Fix Released
Medium
Unassigned

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.

Revision history for this message
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
Revision history for this message
Jaap Karssenberg (jaap.karssenberg) wrote :

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  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.