To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=103354


User ab changed the following:

                What    |Old value                 |New value
================================================================================
                  Status|STARTED                   |RESOLVED
--------------------------------------------------------------------------------
              Resolution|                          |FIXED
--------------------------------------------------------------------------------




------- Additional comments from [email protected] Thu Aug 27 13:26:41 +0000 
2009 -------
After some investigation I see this as a problem that only occurs very
sporadically. In test builds I could not reproduce it at all. Rebuil-
ding the wrongly named index afterwards (using the same command line
and input data) fixes the problem. So obviously Lucene normally uses
the file name we want and only chooses another one in case of an exter-
nal problem occuring infrequently. As the problem is related to ope-
ning or renaming files I assume a network related problem.

I think in such a situation it makes no sense to patch a tool like Lu-
cene that does not even violates any specification. If the usual file
name cannot be used why should we expect to avoid the problem by chan-
ging the Lucene code? If the name is blocked somehow it will be blo-
cked also for our code.

Besides this changing external code always is risky and it should be
considered very carefully if this is justified by the severity of the
problem that should be fixed. Here I doubt this. This can be compared
to other network related build breakers that also nobody would try to
fix by patching the C++ compiler.

So my approach was not to avoid the problem but to make it visible
early. I've added a -checkcfsname flag to the HelpIndexer and added
"-checkcfsname _0" to the corresponding call in helpcontent2/util/
target.pmk. Now if another file than _0.cfs is created the build
fails and the problem is detected long before MSP packaging.

I know that this is no real solution for the problem but it's reaso-
nable considering its frequency of occurrence and the easy workaround
after detecting it. Let's just try and check if this is sufficient.

FIXED


---------------------------------------------------------------------
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to