.ctb write failed – writing to disk

Home Forums cherrytree .ctb write failed – writing to disk

This topic contains 21 replies, has 8 voices, and was last updated by  Sprinterdriver 4 days, 4 hours ago.

Viewing 7 posts - 16 through 22 (of 22 total)
  • Author
    Posts
  • #122895

    hutou
    Member

    Found a workaround : use “save as” to recreate a new database !
    Everything works fine after.

    #122909

    giuspen
    Moderator

    Seems that you edited a cherrytree document with a newer version and then later with an older version.

    Currently (0.35.7) the image table has 8 columns

    db.executemany(‘INSERT INTO image VALUES(?,?,?,?,?,?,?,?)’, images_tuples)

    but in your log I see 7

    db.executemany(‘INSERT INTO image VALUES(?,?,?,?,?,?,?)’, images_tuples)

    Be sure to have the latest version everywhere.

    Cheers.

    #122918

    hutou
    Member

    Yes, you are right.
    Of my Dropbox sync’d computers, one was running cherrytree-hg version 0.29 !
    Perhaps, this could also explain the problem I submitted to you a few weeks ago about the “unprintable” sentence !
    Regards

    #122986

    AlanWalker
    Member

    Last year I had several incidents with CT involving ‘write error’ and, far stranger, CT asking for passwords to a file (ctx) that was already opened.

    I concluded that my misshandling of CT (eg. two instances of CT having the same ctx file open, moving ctx files, etc) were responsible for errors I was experiencing (running on Debian).

    Below see a partial log that I was keeping during the time of problems with CT.

    *********

    2014/05/06

    2014/05/06 14:38 – Cherrytree just experienced another disk write error.

    2014/05/06 – 14:43 just had to kill Cherrytree with xkill. Reopened ct normally. Entering this note data. will now save and close ct.

    2014/05/06 – 14:45 reopened ct. appears normal. just saved .ctx, all seems ok.

    2014/05/06 – 14:46 – saved and exited ct. taskbar icon gone. restarted ct – seems normal.

    2014/05/06 – 14:50 – shut ct down to uninstall unnecessary packages. restarted ct

    2014/05/06 – 14:53 – altered node. saved ctx – seems ok.

    2014/05/06 – 14:55 – altered node, saved ctx – seems ok.

    2014/05/06 – 15:16 – altered node, saved ctx – seems ok. shutting ct down.

    2014/05/06 – 15:35 – started ct, altered 2 nodes saved ctx, exited ct.

    2014/05/06 – 15:49 – restarted ct.

    2014/05/06 – 16:27 – done several node alters and saves. seems ok.

    2014/05/06 – 21:35 – ct has been open for awhile now and the system has been stable.

    2014/05/08 – 11:48 0 cherry tree is asking for passwords to a ctx file that is already open and I cannot exit. and now it is getting a ‘write failure’.

    2014/05/08 – 11:53 – ct killed via xkill

    2014/05/21 – 17:18 – moved ct.ctx while open in cherrytree. trying to save got ‘no permission to write to that directory’; attempted a save the current to the old location – asked for save file format/password – gave info then saved; reopened cherrytree and it took a long time to ask for pswd; then it would occasionally shutdown on start; killed cherry tree, then copied ct.ctx back to orig. location, then cherrytree began to behave irratically – eg. opening two instances of cherrytree; exited ct, uninstalled ct, restarted system, reinstalled ct.

    #123000

    giuspen
    Moderator

    In these days I’m working on the password protected documents and hopefully will produce a safer version soon.

    My feelings of the problems are at the moment:

    1) two instances of the same file opened so one messing with the other

    2) 7zip command line (used for cherrytree password protection) when inserting a bad password extracts anyway the content to a file with 0 size (this behaviour is terrible BTW)

    The points (1) and/or (2) cause the destruction of the database.

    #124290

    Hi. I feel I need to open the case again, as I experience similar problems.

    I’ve run the portable version of Cherrytree, version 0.37.6 downloaded from this site. I have not tested other “versions” (I mean that one that install from exe file, or that other portable one found on portableapps.com).

    I have just got a new computer with Windows 10 64 bit, while the old computer had Windows 7 32 bit. I was working on the same ctb file (located on a common file server).

    When working in Windows 7, I never experienced any unexpected crashes or freeze while working with Cherrytree. But just an hour after I had started working in the same database (only exception is that OS is W10), I got the error message that says that saving the file fails. I tried to /save as/ at another location, but with same result. So I ended up loosing my data (not so much).
    However, I continued working with the same database once again, just to see the same thing happens again an half hour after.

    So this strongly suggest that the problem was introduced when OS was changed from Windows 7 to Windows 10.

    From my own short experience with this error, it seems that it may happens if I do either of the following BEFORE I tries to save file: 1. Create a new node with some contents, 2. Set foreground color to one or more words.
    And of course the database is at my work computer so I have no way of uploading a sample as it may contain “business sensitive” stuff.

    The log file says:
    Traceback (most recent call last):
    File “clipboard.pyc”, line 421, in to_image
    AttributeError: ‘NoneType’ object has no attribute ‘link’
    Traceback (most recent call last):
    File “core.pyc”, line 1523, in file_save
    File “core.pyc”, line 1670, in file_write
    File “core.pyc”, line 1571, in file_write_low_level
    File “ctdb.pyc”, line 60, in pending_data_write
    File “ctdb.pyc”, line 308, in write_db_node
    sqlite3.OperationalError: database is locked
    Traceback (most recent call last):
    File “core.pyc”, line 1523, in file_save
    File “core.pyc”, line 1670, in file_write
    File “core.pyc”, line 1571, in file_write_low_level
    File “ctdb.pyc”, line 60, in pending_data_write
    File “ctdb.pyc”, line 308, in write_db_node
    sqlite3.OperationalError: database is locked
    Traceback (most recent call last):
    File “core.pyc”, line 1498, in file_save_as
    File “core.pyc”, line 1670, in file_write
    File “core.pyc”, line 1563, in file_write_low_level
    File “ctdb.pyc”, line 149, in new_db
    File “ctdb.pyc”, line 387, in write_db_full
    File “ctdb.pyc”, line 275, in write_db_node
    File “ctdb.pyc”, line 481, in read_db_node_content
    sqlite3.OperationalError: database is locked
    Traceback (most recent call last):
    File “core.pyc”, line 1523, in file_save
    File “core.pyc”, line 1670, in file_write
    File “core.pyc”, line 1571, in file_write_low_level
    File “ctdb.pyc”, line 60, in pending_data_write
    File “ctdb.pyc”, line 308, in write_db_node
    sqlite3.OperationalError: database is locked
    Traceback (most recent call last):
    File “core.pyc”, line 1523, in file_save
    File “core.pyc”, line 1670, in file_write
    File “core.pyc”, line 1571, in file_write_low_level
    File “ctdb.pyc”, line 60, in pending_data_write
    File “ctdb.pyc”, line 308, in write_db_node
    sqlite3.OperationalError: database is locked
    Traceback (most recent call last):
    File “core.pyc”, line 3752, in on_window_delete_event
    File “core.pyc”, line 3729, in quit_application
    File “core.pyc”, line 3736, in quit_application_totally
    File “core.pyc”, line 3761, in check_unsaved
    File “core.pyc”, line 1523, in file_save
    File “core.pyc”, line 1670, in file_write
    File “core.pyc”, line 1571, in file_write_low_level
    File “ctdb.pyc”, line 60, in pending_data_write
    File “ctdb.pyc”, line 308, in write_db_node
    sqlite3.OperationalError: database is locked

    Tree summary information:
    ———————————-
    Number of rich text nodes: 68
    Number of plain text nodes: 0
    Number of code nodes: 0
    Number of images: 0
    Number of embedded files: 0
    Number of tables: 1
    Number of CodeBoxes: 0
    Number of Anchors: 2
    ———————————-

    #124353

    Hi. Problem still persists (affecting .ctb file, but not .ctd).

    Changed since last post:
    * Computer is replaced. OS is Windows 10, norwegian.
    * Cherrytree version 0.38.1, portable version.
    * Database has now grown to ~400 kB

    Since last post I have worked only with a .ctd file, not password protected. And that goes very well, I have not experienced any problems at all.

    So I decided to give version 0.38.1 a try, and save my .ctd log as .ctb file.
    The problem occured almost imediately after. The bug is obviously not fixed.

    The database file is located on a network drive, but I doubt that is the problem because other programs doesn’t have similar problems saving files. And also when Save as another file (same session) as .cdt file.

    Log file content:

    Traceback (most recent call last):
    File "core.pyc", line 1578, in file_save
    File "core.pyc", line 1712, in file_write
    File "core.pyc", line 1613, in file_write_low_level
    File "ctdb.pyc", line 62, in pending_data_write
    File "ctdb.pyc", line 335, in write_db_node
    sqlite3.OperationalError: database is locked

    Btw: The tree summary information box should support Ctrl+C to copy to clipboard as plain text.

    In my opinion this is a serious bug. It’s like If it was Libre Office, and somehow wasn’t able to save documents in odt/ods as default formats.

Viewing 7 posts - 16 through 22 (of 22 total)

You must be logged in to reply to this topic.