added usagetracking, regression keywords

@b_michaelsen: The csv file will be written when the office dies or when the
logger will be disposed. I remember that the cws mhu20 has changed something in
the file world. Perhaps you could ask mav for more information. May be you have
to flush the stream.

add fma on cc

Ok, The Improvement program itself is _not_ broken. Logging works.
However, if the logfile (which is open for writing logdata) gets opened (via a
normal file-url dispatch), strange things happen:
- The file show up as having some weird binary content in OOo. However, when
  looking at the file with other tools (stat, cat, vim) the file shows up as
  empty (as expected).
- When the loaded document (however it was imported) gets open, OOo _writes_
  binary garbage into the logfile. This is without ever notifying the user that
  data is changed in the filesystem.

So, as long as the data is not being looked at with OOo while logging,
everything works. All this was tested with the latest fixes for the new buffered
IO introduced with mhu20.

Further investigation showed the following root causes:

- Premature optimization in comphelper::UiEventslogger
  and logging::FileHandler skip flushing because they expect
  osl::File to be unbuffered. Currently nothing calls
  logging::FileHandler::flush().
  @fs: Should logging::FileHandler::publish() do so, or is this
  client expected to explicitly call flush() on the FileHandler?
- This leaves the logfile as an empty (zero byte) file.
- OOo inappropriately handles zero byte files. If one clicks File->Open
  it shows an import dialog. Even if one presses "Cancel" the file gets
  overridden (with binary garbage/likely an empty storage). The same happens
  when the file is opened and closed (_without_ saving).
  Opening the file read-only fixes this for the usage tracking, but the issue
  is serious enough in itself.
  @mav: Please have a look.

removing oj from cc as this is indeed not related to cws oj18.
Adding mav to cc because of opening empty files issue.
Adding fs to cc because of flush issue in logging::FileHandler.

Should we separate the issues?

Separated out the zero length file issue as issue 105894 (might be a showstopper
in itself, mav will investigate).

Therefore removing mav from this issue.

started work in cws oooimprovement5

fs->b_michaelsen: sorry for the delay ... I'm somewhat undecided with respect to
"flush". Given that you say nobody currently calls XLogHandler::flush, it might
be a good idea to add this to the publish call, just to catch the other
occurrences where logger clients forgot the flush. On the other hand, it'd be
somewhat hacky, as it would render XLogHandler::flush useless (it's effectively
a no-op then).

Given that the only existing client for XLogHandler::publish currently is the
Logger implementation itself
(http://svn.services.openoffice.org/opengrok/xref/Current%20%28trunk%29/extensions/source/logging/logger.cxx#224),
I tend to think that EventLogger::impl_ts_logEvent_nothrow should not only call
"publish" at each handler, but also "flush". This way, it could be considered an
implementation detail of the Logger implementation that publishing a record also
means flushing all handlers where it was logged to.

set target

fixed in cws oooimprovement5 in revision 276854.

@fs: Could you please review the changes made in extensions/logging?

> @fs: Could you please review the changes made in extensions/logging?

Looks fine to me. Thanks for taking *this* road ;-)

@of: reassigning, please verify

of: Improvement program gives results and can display them in OOo.