On Wed, 2012-03-28 at 10:04 +0200, Cor Nouws wrote:
Indeed ;-) See issue fdo#47983
Which comes down to combination of problems:
* of not easily being able to push more information into the
file ucb to be able to flag that we want to call osl_syncFile
at just-this-one-place (saving a document), due to some
"shove arguments into a struct into an any" design - or
perhaps I'm missing something.
* the desktop/ migration code heavily using UCB.
* the desktop/ migration code being write-happy, and
re-writing the same couple of files 40 times or so
each ;-) [ and this is before the berkely database
cruft ]
So - unclear how to deal with that really. A very quick, very ugly hack
would be to stop the file ucp doing it's (new) sync if the path is
in /tmp or in your configuration ( I suppose ). Not at all beautiful,
but functional.
Failing that, we could re-open the file, purely in order to 'fsync' it
(conceptually yucky too) in SfxMedium::TransactedTrasferForFS_Impl and
pull the fsync out of the UCB's write (where it belongs). Or - we could
do something nastier ;-)
Thoughts Stephan ?
Hmm,
Michael.
--
michael.meeks@suse.com <><, Pseudo Engineer, itinerant idiot
Context
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.