incubator-ooo-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject [Bug 92377] Document lost (0 ko) when the hard drive is full and you try to save it
Date Mon, 10 Sep 2012 15:41:55 GMT
https://issues.apache.org/ooo/show_bug.cgi?id=92377

openoffice@dreamchaser.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |openoffice@dreamchaser.org

--- Comment #13 from openoffice@dreamchaser.org ---
It is not necessarily the file system to which the document is being saved 
that causes the problem.  
On a FreeBSD (9.0) system, this scenario happens when the /var partition is 
full.

While that *should not* be a common occurrence, 
nothing in OO's behavior should cause it to truncate an existing file 
before a replacement is established.

In the case I encountered:

I tried to save a (Writer) file.
Got the message cannot save file, file is locked by another user.
It wasn't, I presume that is a misleading error caused by the full /var
somehow.
I did a "Save As" with a new name on a file system which is nowhere near full,
the same one containing the original file.
The save appeared to work,
but when I went to quit OO claimed there were unsaved changes.
(I am a bit fuzzy on the exact operations I performed, unfortunately.)
So I saved again with yet another name, then quit.
Both of my "emergency backup saves" appeared to work;
OO complained only about files being locked by another user.
All three files, including the original, were truncated to zero length.

In my configuration "Paths", the only files on /var are:
  Temporary files           /var/tmp
I'm guessing something in the undo history or auto-backups may be causing this.
(I don't know anything about internals; wild guess).

I have 
  "Always create backup copy"
checked.  It is created when a save is done.
The following procedure when saving *may* avoid the truncation,
in the event the current procedure does things in a different order.

  Attempt to write the file with a new name.
  If successful:
    Attempt to rename the original file to a backup name.
    If successful:
      Attempt to rename the saved (new) file with the original name.
      If successful:
        done, yea!
      Else successful:
        Inform user where the original file is located and unchanged;
        Inform user where the new file with the temporary name is located.
        Suggest possible problems to look at;
        In particular, which file path caused the error
    Else unsuccessful:
      Complain with appropriate error message,
      leaving the original file intact (barring o.s. screwups)
      Suggest user check the original file date and length before proceeding.
      Inform user where the saved file with new name is located.
      Inform user which file path encountered the error.
  Else unsuccessful:  
    Complain with appropriate error message
    leave the original intact
    Suggest user check it's date and length before proceeding
    Inform user which file path encountered the error.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Mime
View raw message