Date: prev next · Thread: first prev next last
2012 Archives by date, by thread · List index


On Wed, Mar 28, 2012 at 8:24 AM, Michael Meeks <michael.meeks@suse.com> wrote:

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.

or you could actually call sync() directly from the save() method once
your done with your writing (*),
that push up some implementation details... but that still would be a
less ugly than the hack above

Norbert

(*) I'm assuming here that this sync really matter only when saving
'documents'... and that we could live without it for other write...

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.