https://bz.apache.org/ooo/show_bug.cgi?id=126990

John <john.h...@yahoo.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |john.h...@yahoo.co.uk

--- Comment #2 from John <john.h...@yahoo.co.uk> ---
Created attachment 85563
  --> https://bz.apache.org/ooo/attachment.cgi?id=85563&action=edit
An example .odt file which opens as "full of ######"

This file is taken from
https://forum.openoffice.org/en/forum/viewtopic.php?f=7&t=1532&start=420#p372812.

Notes:

1  It is a .odt file, but it is not a zip file, and it has no internal
structure (no content.xml, manifest.rdf etc).

2  When the file is opened with a Hex editor, it is 27,605 Bytes, and each byte
is zero.

3  When the file is opened by Writer, Writer assumes it must be a flat, ASCII
TEXT file.  Writer brings up the ASCII Filter Options pop-up.  The document
then appears with 9,999 x "#" as word 1, a paragraph return; 9,999 x "#" as
word 2, a paragraph return, and the remaining "#" as word 3. Presumably Writer
has a 9,999 character limit on a word and adds the paragraph return.

4  The fault seems to have the characteristics of Writer reserving some space,
naming that space postcol literature II.odt, setting the space to all zeros ...
and then failing to write the correct data to the file.  The file content is
therefore all zeros.  Does this occur because Writer was somehow prevented from
completing the write?  Could shutting a laptop lid too quickly cause this?

5  There are numerous issues relating to saving files across networks, where
the slow speed of the network highlights problems.  See Issue 107558 - A hidden
step while writing OOo files? which reports that AOO continues to do saving
AFTER the bar stops moving across the bottom of the screen.  Could it be that
users think that the save is completed when the bar stops moving, and slam the
laptop lid shut, whereas the save has not completed?

See also Issue 104661 - Saving to file should take place in a process
independent of the GUI 

Some form of atomic save is needed where the save can be guaranteed.

-- 
You are receiving this mail because:
You are the assignee for the issue.

Reply via email to