Issue 92377

This is a duplicate from Issue 91468, but as no-one answered to it and I could
not set it as unconfirmed, I created again.

*** Issue 91468 has been marked as a duplicate of this issue. ***

Any news ??

@pagalmes
This is a dangerous issue to test because a full disk can cause all sorts of
problems including impossibly slow performance and could even lead to directory
corruption. Was this your main disk or a secondary one? 

A system cannot run properly with all its disks full. You get plenty of warning
messages from Windows well before a main disk gets full. If you have more than
one hard disk, the easy 'workaround' would have been to save the document on
another disk before making some space on the full one or possibly saving on
removable media.

Although the issue is potentially serious, full disks don't happen very often,
so few users will be affected, so this issue may not get immediate attention or
confirmation. 

@pagalmes
This is a dangerous issue to test because a full disk can cause all sorts of
problems including impossibly slow performance and could even lead to directory
corruption. Was this your main disk or a secondary one? 

A system cannot run properly with all its disks full. You get plenty of warning
messages from Windows well before a main disk gets full. If you have more than
one hard disk, the easy 'workaround' would have been to save the document on
another disk before making some space on the full one or possibly saving on
removable media.

Although the issue is potentially serious, full disks don't happen very often,
so few users will be affected, so this issue may not get immediate attention or
confirmation. 

In fact, this issue happens. You don't need to have your main system disk full. 

A few example:

- many users have now USB external storage.
- Or I can use a USB key and work on a document on the key.
- or you can have shares on file servers (often used in companies)

I haven't tested, but I also suppose that if you have a quota on a resource, the
issue will be the same.

Thus, this case happens. In fact, a user which had lost documents came back to
yell at us, that's why I declared it. ;-)

Regards

-> mike_hall : please check my last comment

@pagalmes
OK, point is well made. I think I have a way of testing this. Will revert.

Apologies for duplicate entry previously...

Have tried very hard to create this problem with a 100Mb Iomega Zip drive.

I have not managed to confirm the issue with Writer with 3.0 and m35 on Win XP
or with 2.4.2 on Vista. In every case the original file is not corrupted when
the I/O disk full error appears.

There were several odd effects though, for example a corrupted file was written
at one point that turned out to be the first 22 pages of a document. Also, the
lock file is deleted when you start to save a file, so protection is lost. I
think someone else could then open the file read/write, not tested.

Will also try with Calc.

Same thing with Calc with m35. Can't damage the file on a full drive, but the
lock file is deleted. I will raise an issue for that.

Re the reported issue, it's Worksforme with a zip drive, but a Memory stick
might do something different. 

@pagalmes
What do you want to do now with this issue?

See also http://www.openoffice.org/issues/show_bug.cgi?id=95995

I will try to reproduce the issue with some other media.
If I can't, them I will close the issue.

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.

I also had 
  Save auto recovery information 
set for every five minutes.
Interestingly enough, I received no errors from this,
although it seems like auto recovery save most likely also happened at some point 
while /var was full.

/var was actually full, not just showing 100% from df.
I believe it was at 109%, and that's about the slop specified in the file system.