Le 23/05/2017 à 22:44, Rory O'Farrell a écrit :
On Tue, 23 May 2017 22:11:37 +0200
Hagar Delest <delest.ha...@gmail.com> wrote:
Le 22/05/2017 à 10:16, Rory O'Farrell a écrit :
On Mon, 22 May 2017 09:57:31 +0200
Peter Kovacs <peter.kov...@posteo.de> wrote:
Thanks for the sum up.
Still I think we should find a solution.
So i adf backup at the start of editing session to the list.
Is there a bug for this?
There certainly ought be, but I cannot point to one.
I think Hagar has remarked on Forum of one instance of spellcheck or file corruption on
his (work) Windows system, and with great respect, that might be due to a freak close
down on his part. In this sort of fault finding the user reports of their actions are
"unreliable", as they often feel they are being trapped into an admission of
improper computer use.
In ten years of heavy use of StarOffice/OO (last years on linux) I have
experienced file corruption or spellcheck problems on very few occasions,
caused by unexpected power cuts in storms. My computer experience goes back to
1965 (Fortran II on an IBM 1640), so I am aware of the need for system in their
use,
Rory
There is a bug report for the ### and for the dictionary issue (but the latter
was closed as fixed).
Never heard of a feature request to have a backup of the
registrymodification.xcu file. Sounds a good idea but still needs tweaking from
user to restore the former file.
Hager,
My thoughts on a backup were that the file opened at start of an editing
session should be backed up, so that in the event that the edited file
corrupted (the ### problem) the previous version remained available. It is bad
enough to lose a session of edits, but how much worse to lose the entire file
as often occurs with the ### problem Having regard to the large size of
current hard disks, I feel that this backup procedure (might it need to be a
backup of a backup?) should be enabled by default
I thought the backup proposed by Peter was for the registrymodification file.
After second reading, it was about any file at all. Understood. Of course, that
should be the standard process.
I think that the new file should be written as a temporary file next to the
original one and the original deleted and the new one renamed after the system
has confirmation from the OS that the save is complete.
I think that when saving a file in MS Office, we can see such temporary files
appear and disappear when saving.
As for the spellcheck corruption, I noticed quite recently that it could be in
fact a temporary glitch. It happened on a big file (25MB), sometimes all the
text is underlined and sometimes there is no underline at all (even where there
should be). This behavior disappear after some time (haven't yet investigated
what is needed, reboot or Windows session...)
Perhaps such a file is at the limit of what OO can comfortably handle. I know
from my own experience that large files can be slow to format correctly,
depending where in the file the cursor was last positioned. The formatting
seems to start at the cursor position and seems to take several passes through
the file until it stabilises. The ### problem you report may be an instance of
this and might have cleared with the stabilisation of the formatting.
As far as I remember, even waiting for a long time doesn't change anything.
No real time to investigate when that file is open but will try to record if
there is something special.
Hagar
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
