To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=49225
Issue #:|49225
Summary:|$ character in user dir gets lost
Component:|udk
Version:|680m96
Platform:|All
URL:|
OS/Version:|All
Status:|NEW
Status whiteboard:|
Keywords:|
Resolution:|
Issue type:|DEFECT
Priority:|P3
Subcomponent:|code
Assigned to:|dbo
Reported by:|ab
------- Additional comments from [EMAIL PROTECTED] Fri May 13 04:44:21 -0700
2005 -------
This issue probably is responsible for the problem described
in i28593, at least for some of the cases. The user installa-
tion does not lead to a valid result - although it does not
fail explicitely - if the system user path is mapped to a
network directory containing a directory ending with - or
maybe also only containing - a $ character. This is not very
unlikely to happen as in Windows giving a shared folder a
name ending with $ does mean to hide this folder. It can be
accessed using its name including $ but it is not visible
for other users - e.g. in the Windows Explorer.
To simulate such a user path I patched sal\rtl\source\
bootstrap.cxx: Bootstrap_Impl::getValue():
oslSecurity security = osl_getCurrentSecurity();
// osl_getConfigDir(security, ppValue);
OUString val( RTL_CONSTASCII_USTRINGPARAM( "file://ab-1/test$" ) );
// OUString val( RTL_CONSTASCII_USTRINGPARAM( "file://ab-1/test2" ) );
rtl_uString_assign( ppValue, val.pData );
where test$ and test2 are the share names of two different
directories on my own machine - using the shared dialog of
Windows Explorer.
A user installation with "file://ab-1/test2" works perfectly
while using "file://ab-1/test$" leads to the problem descri-
bed in i28593 (Basic does not work because the Basic user di-
rectory is not found).
I've debugged the problem and finally found that the $ gets
lost when using bootstrap.cxx: Bootstrap::locateUserData().
In the scope of this call Bootstrap_Impl::getValue() is cal-
led with name == "UserDataDir". The execution reaches line
533 in bootstrap.cxx 1.32 with the correct string **ppValue
including the $, but the further_macro_expansion flag leads
to a call to macro.cxx: expandMacros that deletes the $. I
assume the $ handling fails if no valid macro name follows
the $ leaving the original string without the $ char.
Basic should not be the only functionality that does not
work as all user related pathes shown in Options/Paths are
wrong. I think an invalid - not even detected - user instal-
lation is worth a 2.0.1 target.
---------------------------------------------------------------------
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]