hopefully this fixed the strange autorecovery related dataloss fdo#42899

also this is a fix for bnc#817477
Disabling the optimisation of copying the library container storage
to target storage for the moment ( hopefully after some rework
it might make some sense to re-enable this code ) The problem here is
there is a tragic flaw in the api implementation. In the implementation
the library in-memory model state reflects that the library model
has been saved to storage but not the library container storage
as you ( or at least I ) would expect but actually any storage.
So to illustrate the problem, during autorecovery when the
basic library containers are stored to the autorecovery file the
library pImplLib->implIsModified() is set to false, any subsequent save
attempt will think the library is not modified and will attempt
to the librarycontainer storage to the target one. However, in this case the
source (library container) storage has never been updated with the changes
from memory.
Can't we simply only update the 'implIsModified' state only if the library
container's own storage and the storage to store to are the same ?
Sounds like a good idea, unfortunately this is not possible due to the way
that sfx spaghetti code uses temporary storages for even own copies and
also because it sets the new root storage for the library container
after the library copy happens. ( some stuff in dbaccess appears to
depend on this as well )
AFAICT for any document save/saveas etc. operation the librarycontainer's
own storage and the storage we save to are *always* different.
So for the moment it seems best to *always* write the storage from the
in-memory model.

Change-Id: Ia24e7a6119558497d901370dbc0986101bde4de9

0 files changed, 0 insertions, 0 deletions