On 12/31/2015 10:30 AM, Max Merbald wrote:
Hi,
let me say a few words on this too:
I have had the autosave option enabled for ages and I've never
experienced a problem I'd relate to this. In the contrary, it has helped
me a few times to retrieve a document I've had a problem with (such as
losing it for some reason or other. I think users will benefit from the
autosave being enabled by default.
I also have autosave enabled, and have not experienced any problems with
it personally.
I think those who consider it a real problem, justifying not enabling
autosave by default, should identify or create an independent Bugzilla
entry just for it, and add the information from any prior e-mails etc.
This sort of discussion is exactly why I feel that the first step in any
debug effort should be collecting and organizing information, prior to
even thinking about debug strategies, let alone workarounds and fixes.
On the other hand I think there is a number of things in the autoformat
section that shouldn't be enabled by default as they might just irritate
an inexperienced user who cannot figure out why unwanted changes in the
text are made. For the same reason they might annoy experienced users.
The first thing I do with any word processing program is go into the
various options and turn off all the automated changes I can find.
Think about it - and a happy New Year!
Max
Am 31.12.2015 um 19:15 schrieb Hagar Delest:
Hi,
I step in this interesting thread, for my 2 cents opinion.
First I've never heard of an "extremely obscure, semi-inconsistently
ir-reproducible bug in AOo, EO, and LibO that is triggered when
"Always create backup copy" is checked."
Even if I spend much less time on the forum for some months, I don't
recall problems linked to the automatic backup. Could you provide some
evidence about that?
NB: I use AOO everyday with the setting activated, never had any
problem for years.
Second, one of the reasons for the automatic backup option not being
checked by default could be privacy/confidentiality: these files are
not secured, meaning that someone could delete a file from his machine
without knowing that a copy is available in clear for anyone having
access to his profile. Rather a corner case but still to be considered
IMHO. Except if we can have a encrypted process (but that's going
rather far).
My last point is that IMHO, there is a common denominator in all the
problems with the files, from the ### problem (for which I opened a
bug report and still record all the occurrences I see in the forum) to
the pics lost and blank documents like in this topic. Could we
consider the saving process and its robustness? I remember a time when
there was absolutely no problem with save operation. Then suddenly,
the ### issue appeared.
There is perhaps a problem when the new file is saved, okay. But what
is not acceptable is that it seems there is a time when all the eggs
are in the same basket and if there is a problem, then all is gone.
Could we imagine a process where in the final steps there are 3 files:
the one in the temporary files and the actual final one in its save
location (same new content) and the former version of the file (last
manual save). Once the actual new file is written, then allow AOO to
remove the temporary file and the former version.
My point is: perhaps having a look at the save process could give some
hints on possible vulnerabilities to unexpected events (like power
loss, ...).
Hagar
Le 30/12/2015 20:33, toki a écrit :
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 30/12/2015 02:33, Dennis E. Hamilton wrote:
Is there a Bugzilla # on this?
I don't know.
I've forgotten who told me about it, but the consensus was that it was
easier to work around it, by ensuring that both "Save AutoReceovery
Information" and "Always create backup copy" are unchecked, than trying
to recreate the situation in which the bug is usually triggered.
jonathon
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBAgAGBQJWhDF2AAoJEKG7hs8nSMR77fAP/iqhGVetlkFWcWU+Nqn6sty0
7q9kjQo6LQLVSTcXJKwM1yfjRm/UvDY+lt8XpNMRVyH4iOw2Su9cGvcV3nkperMv
z8f3JmfUZJsBtqmwDAa3U8kcF8/C1wpWHPVeF3TK750kzGTdij5zAi/yQ2CwiiPi
VpiTyLRsq34ICaXyxnbaTWVm8it+p7AOlC5cnXH/sqUeiHNJj/M6zu3xp1zeG5gM
co4xcg8JUIjoUFyBJhGzWeWb4B9zBtNT69GfsZ0u6lRzxQGLZQ2tAtNAGzwi/dzr
qMOGN/UVjx3b86DjbIJ6a1WmfUUeM5TIbyLhUPAP5apQJpkcH2NRvYDitQJeRz2d
sg/SUmFPCAunUYlnie+JYilMdvbCGOXctzseU1QgWJcA0dMf/daWjRcgaSmmNPvr
wdz1Zkx6QnwVhOzO6dGgTqvwoaRMH1mcavnxqHlDXdzPDci/jXh35GJjPV76J968
XtzbPohFPkQRrRkkBb6s2fslbBqscbJWdX0h5iQB2MlL4VcXLi9ZuErJK9nHbTq2
33dUg6qpgVT+HAvsTAiJXpV4PsJ6r61Ey2hYZnnKlhayOvXXZZ3P3UjndFE+4Lw1
GkYkQ/5KNB7+Nn++jTnMgIbNUskUU2XyBNZu/isEukEougDdl7bkDw+7XaVyPwwH
gpCNrokVzlW/Hw10oPPg
=uGdG
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
