Framework issue.

I realized that I did not fully clarify the situation in which this even 
occurred.  This problem only occurred with version 109 on an XP machine.  Our 
NT machines with OpenOffice version 109 on them, do not exhibit this problem 
and can open these same files with no problems.  I have currently been unable 
to test this out with a newer version of OpenOffice.

Tried OOo 2.0RC1 on Win98SE (on two separate workstations)
opening files on network path (on a Windows2000 server) with
consistent negative result exactly like this issue#53184. 
I still get the error 'file did not exist'. 

But outside of OOo, I can copy and paste said file/s from 
my Win2kserver to my Win98desktop, and successfully open the same 
with OOo.

If I try to save a file to a network path, OOo 2.0RC1 will give a
path error message, but if I check the file on my server, said file is
successfully saved.

My other concern is that there was another (simililar) issue no. 51026, says it
was Resolved, but I dont think so. OOo might quickly dismiss this old issue as
resolved; I hope not.

Rally de Leon
ralleon@gmail.com

Tried OOo 2.0RC1 on Win98SE (on two separate workstations)
opening files on network path (on a Windows2000 server) with
consistent negative result exactly like this issue#53184. 
I still get the error 'file did not exist'. 

But outside of OOo, I can copy and paste said file/s from 
my Win2kserver to my Win98desktop, and successfully open the same 
with OOo.

If I try to save a file to a network path, OOo 2.0RC1 will give a
path error message, but if I check the file on my server, said file is
successfully saved.

My other concern is that there was another (simililar) issue no. 51026, says it
was Resolved, but I dont think so. OOo might quickly dismiss this old issue as
resolved.

Rally de Leon
ralleon@gmail.com

I can confirm this issue on Windows 98SE.

Confirm from votes and many recent messages, as follows.

* cwchia: Windows XP SP1 and OOo does not work with UNC paths, but mapped drives
work
* StuartGMC: Windows XP SP2 and OOo 2 does not work with UNC paths (a bit unclear).
http://www.oooforum.org/forum/viewtopic.phtml?p=101817

* jcrisman: OOo 2 on Windows 98SE, Windows ME and Windows XP does not work with
UNC paths, but mapped drives work.
* tyfarquhar: OOo 2 doesn't work, but OOo 1.1.5 does.
http://www.oooforum.org/forum/viewtopic.phtml?t=25086

* chreestopher: Winows 98 SE does not work with UNC, but mapped drives works. 
Also Windows XP does work.
http://www.oooforum.org/forum/viewtopic.phtml?t=25705

* Jeff Christiana: "A UNC path to a 2000 server works and A UNC path to a 2003
server Does not."  Then it works with mapped drives.
http://www.oooforum.org/forum/viewtopic.phtml?t=25958&highlight=

\\app_srv\CIS_SHARE\CIS_SHARE\Grant 
This will not open. App_srv is a NT 4 Server 

\\File_srv\CISOPERA\Allisons courses 
This will not open. File_Sev is a 2003 server 

\\bh-srv\BH_DATA\BHADMIN\Administration 
This will open "Note that BH_Data has an _ 
But the server name has a - not an underscore 

In all cases the "-" works fine when opening UNC files 

All my servers that have _ in them will not alow us to open UNC.. 
Unless we map a drive and then there is no problem opening UNC files from an _ 

Looks like if ther is an _ in just the document name it opens fine. 

The server exibiting the problem in my instance is a Netware 5.1 Server 
(Service pack 5) and it also has an "_" in its name.  

I have been following this problem since beta versions of OOO 2. Version 1.1.4
CAN open files in unmapped folders on the local network but 2.0 CANNOT. Version
2.0 CAN open files in unmapped folders on the local network when running in
WinXP but CANNOT do it in Win98. I've tried with files in Linux and WinXP Pro
servers.

Using Windows XP, OpenOffice 2.0, when I try to open directly \\inf-
gris\publico\install.doc using the explorer everything goes ok, if I
try \\inf_negro\publico\install.doc it waits for a second or so, and
do nothing.

I think the problem is in the '_' in the name of the servers. Have 
similar problems with programs that in some way need that the server`s
name accords to DNS system, that does not allows underscores.

I had the same problem now occur on an NT machine today.  And again there was 
an underscore in the name of the server.  This time the file is far more 
important and easy access is a necessity so I sure hope this issue is resolved 
in a new version soon.  

I had the same problem now occur on an NT machine today.  And again there was 
an underscore in the name of the server being accessed.  This time the file is 
far more important and easy access is a necessity so I sure hope this issue is 
resolved in a new version soon.  

I can confirm this is is an issue for us as well. In fact it it even more
grievous for us since we have a samba controlled network environment and use
roaming profiles to allow students to login anywhere and access their home
drives and application settings. Since many of the OpenOffice preferences refer
to networked storage areas, OpenOffice runs like a fat dog in a tarpit.
Again it seems to be because our file servers have the "_" character in their names.
I have tried changing the file locations to reflect the mapped drive letters in
stead of the UNC path, but the options menu seems to have a hard time working
with teh "_" in the UNC as well since it will not let me edit preferences which
contain our file server UNCs.
*** Note *** All our networked drives are mapped to a drive letter, but the
preferences still refer to the locations by the full UNC path, so if I could
change the prefs values I'm sure OO would run like greased lightning odd a
teflon pan.
OpenOffice 2.0 final running on Windows XP pro Service pack 2 in a networked
SAMBA domain running Samba 4.0.14a off Debian Sarge (stable) 

I got the error ("file does not exist) in OO 2.0 + Win98 trying to open
\\Server\Temporal\temp.sxc and \\Server\Temporal\temp.odt. No spaces or
underscore. However, I managed to save a new document in that location without
errors.

I can confirm that I have the same problem on 2 Win 98 machines which cannot 
access files on the LINUX Mandrake 10.1 server as already described by several 
people.

And, additionally, OOo 1.9x-2.0 cannot open files on a local Windows (XP)
machine by double-clicking it, if the filename contains characters that do not
map to the current ANSI charset of Windows (issue#51233), obviously using ...A,
not ...W API; using File|Open works, though.
Maybe it's somehow related to this UNC issue?

I am also haveing problems when there are spaces in the file name or path.  For
example

c:\windows\temp\cnh.xls - works
c:\windows\temp\cnh worksheet.xls - doesn't
c:\windows\temp\cnh-worksheet.xls - does 

I hope this helps

Shane

I recently installed OOo v.2 on some computers in my office LAN.

Server :    Win2K server
Workstations: win98 and winXP pro

1.    PROBLEM: From a win98 workstation, when I try to open an OOo v.1
file residing on the server or an xp machine I get a "file does not
exist" error message.

a.    All file manager functions eg. copy, move, properties etc works
and I can open text files(residing on the server or another winXP
workstation with notepad from the same win98 workstation.
b.    Folder permissions are open to EVERYONE-Full Control
c.    I can open the same file (residing on the server) from another
workstation (win98) running OOo v.1.14 or winXP running OOo v.2
d.    Same file (residing on win2k server or xp pro workstation) copied
to win98 workstation can be opened and works normally.

Hope you could let me know how problems 1 (high priority) and 2 can be
solved asap as I would like adopt the OpenDocument standard across all
my workstations in the office and at home.

Thanks.

Daniel Chern

Ours files are stored on Samba server and this issue doesn't happen with Windows
2000 SP4 accessing this file server, but it happen with W98SE machines. 

To try open doc files with OO 2.0 installed on W98SE this results: "file did not
exist". 

This problem doesn't happen with OO 1.1.2.

some things have been mixed up here.

All comments that are related to the "file did not exist" message belong to
Issue 51026, which has already been fixed.

This issue deals only with UNC path, where the server name has a "_"
(underscore) in its name. If this is the case, files cannot be opened form the
windows shell (meand windows explorer) by doubleklicking on it. I noticed that
on Win98SE und WinXP, using a samba share.

That means files like
\\sv_01\share\somefile.odt
would not be opened by a doupleclick

but 
\\sv01\share\somefile.odt
are ok

Opening from within OOo (using the Windows-Style FIle Open Dialog) works.

I can confirm this issue on Windows XP Professional. The file opens, if I
replace the '_' character with '%5f' (url escaped). Still, the file then opens
read-only, but this is another issue. 

I can confirm this is an issue on Windows XP SP2 (2600.xpsp_sp2_gdr.050301-
1519) using both the current stable OpenOffice 2.0.1 release and the 
2.0.2rc1_060213_Win32 release.

Opening files von UNC pathes works great (and allows saving the file after it's
open) if the full path doesn't contain *any* underscore. (OOo 2.0.1, Windows XP)

Same story here: hundred XP SP2 or XP x64 machines, NONE, I repeat, NONE can 
open ANY Office file directly from UNC path by simply double-clicking on it.
This is a HUUUUGE issueu, it shouldn't be unresolved after 8 MONTHS and plenty 
of posts.

I've tried to reproduce with OOo 2.0.2 rc4. I've had unc path with underscore to
another Windows machine and to a solaris samba drive. I can't reproduce. Is it
because of OOo 2.0.2 doesn't have this problem or because the network settings I
have don't cause such an error?

Tested with OOo_2.0.2rc4_060227_Win32Intel_install_de.exe. Still doesn't work if
*servername* has underscores. Works if rest of the path has underscores (which
didn't work for me in 2.0.1: documents with '_' in the path (not the
servername), where opened read-only. ))

The share I'm trying to connect to is on a Windows 2000 Server machine. 

Setting target

We can't create servers with underscores in name in our network. Due to
timeframe and missing resources I'm retargeting to 2.0.4.

I have this same kind of problem. But only when a file, already opened by
another user, is reopened. The fileserver used here is Netware 6.0. The expected
behavior is to open the file as read-only. Which is achived by opening the file
inside the Writer but not using the driver letter mapped by the novell login.

I don´t know if someone is having the same issue.

By the way, opening any file using the driver letters works normal. The issue is
related only to the fact of someone trying to open a already opened file by
someone else.

>We can't create servers with underscores in name in our network

Perhaps an easy hack is to add the underscored hostname to LMHOSTS with the IP
address of an existing server.

http://support.microsoft.com/Default.aspx?kbid=150800

TM->JSK: Please have a look. Do we have the resources to build such an environment ?

andreschnabel->tm:
if you ask "us" as a community it should be simple to setup such an environment.
Please tell us, if your engineers are able to use any kind of virtual machines
(e.g. VMWare). I'm shure, anyy community member could set up a VMWare session
with Linux / Samba and a smb-Server name with a underscore.

You only need to tell what kind of virtualization and where to upload.

I accidently came across this issue. I don't know why tm didn't answer but let
me do it instead: yes, a VMWare image would be fine.

*** Issue 72524 has been marked as a duplicate of this issue. ***

I also can reproduce this issue with OO 2.1 on WinXP.
I do not have VMware to create virtual machine, but I do have Virtual PC 
(which is free now).
I can create Virtual PC machine image and upload that. 
Will this help?

cd->sb: Please take over. HRO and I checked this problem. Hennes was able to
reproduce it and we think that's a problem in the INetURLObject::ScanDomain()
implementation with NetBIOS names containing a "_" character.

@cd:  The (succeeding) test of "file://xxx_yyy/abc" in
tools/workben/urltest.cxx:1.36 l. 1153 shows that the problem cannot be a simple
failure of INetURLObject.  So, as discussed offline, I hand this issue back to
you, but let me know when you need any debugging help.

Dear developers,
any progress with this issue?
Thanks a lot!

cd: I will check this bug as soon as possible, but currently I have many 2.2
tasks to fix. Debugging this problem will need several hours/days as we again
don't know where the root cause could be. Therefore we have debug the whole
loading code.

cd->hro: Please take over. You already checked the issue and could reproduce it
on the VirtualPC image. As discussed with KSO we should track down this issue as
soon as possible. I am busy with other important task.

VPC image with underscore in host name is still available upon request.
Please do not hesitate to ask (mail me at kpalagin@openoffice).
Thanks a lot for your attention.

*** Issue 73928 has been marked as a duplicate of this issue. ***

Issue http://www.openoffice.org/issues/show_bug.cgi?id=64764 describes very 
simmilar behavior.

Hi hro,

is there a solution in sight?






----------
added myself to CC

I highly doubt it - it's a 2+ YEAR OLD ISSUE and still no solution.
This is clearly pathetic.

Maybe fixing "broken unicode support in the command line" (bug 59251) could
solve the issue automagically? The referred regression had also been introduced
in 2.0b...

As I see it the reason for this bug is that OOo internally treats all file names
as URLs and it parses all URLs in the same way, it doesn't make a difference
between file and http URLs.

As hro told me, unfortunately underscores in host names are forbidden in URLs.
Perhaps we can introduce some special treatment for file URLs wrt. underscores
in host names. 

Sure, underscores are forbidden in DNS hostnames. That doesn't mean such
hostnames aren't commonly in use at sites with clueless sysadmins, though. Also,
there has not traditionally been any such rule as far as I know for Windows
machine names, so there is a lot of historical ballast here that weighs in at
many sites. Ever heard the phrase "be liberal in what you accept, strict in what
you generate"?

It's trivial to fix this bug. One can either make underscore fully equivalent to
letters, or use whatever more finesse one feels necessary. Will attach a trivial
patch that does the straightforward thing, just treat underscore like a
letter... I couldn't be bothered with tracing the workings of urlobj.cxx any
closer and do something more refined.

Created attachment 43966 [details]
Trivial patch, feel free to refine

Thanks for the patch. Both experts for the code (hro, sb) are on vacation
currently but they will surely have a look on it when they will be back. 

But please don't call anything in this area trivial. We can call this an easy
fix as the obvious code changes can be written quite fast (as you have proven).
But changes in this area can have a lot of side effects and we need some more
thinking and also testing. So overall it will be an effort that I wouldn't call
"trivial."

Because of this issue. We have had to pull back all our efforts in going 
OOo... :-(   All because of this stinking underscore problem. I am sorry but we 
are a Microsoft server site and have hyphens and underscores in lots of 
servers. And we are not going to change that. I find it absolutely hilarious 
that this issue cannot be solved. I have been following this since the release 
of 2.0.....

Well, fortunately this issue *is* going to be fixed. And this is a good thing as
meanwhile the demand is visible. But it is not wrong to wait for the demand for
a change of code that was written because it is following an established standard.

The real problem is how Microsoft treats standards and that users of MS software
always see the problems caused by those who follow the standards and not by
those who violate them. I like what Paul Tomblin wrote about that: "I love the
way Microsoft follows standards. In much the same manner that fish follow
migrating caribou."

Standards compliance is especially important for cross platform applications
like OpenOffice.org. So it is not surprising that we try to follow them as much
as possible and deviate from them only if necessary and if considerable demand
for doing so has been shown. 

tml,
thank you very much for your patch.
It is integrated into version 2.2 of Russian derivative named OpenOffice Pro 
(http://www.i-rs.ru/download).

Testing has revealed that Office running on XP (possibly Vista and Win2000 
too) can access server (XP, no other server OS was tested)with underscore in 
name.
If Office is running on WinMe (and possible on Win98) it still can't access 
server with underscore in name. 

Please see if you also can fix the problem on Win98/WinMe clients.
While at it please also consider http://www.openoffice.org/issues/show_bug.cgi?
id=74820.

Thanks a lot.
WBR,
K. Palagin.

Correction - patch works just fine on both XP and Win98.

Mathias,
any chance of integrating this patch in 2.2.1?
P.S. Underscore and the like were allowed in NetBIOS names since the very 
begining (in 1985 or so) and that was not governed by any standard. So this is 
classic case of having to support legacy even if it is not compliant. This is 
true for them (they just could not stop supporting strange characters) and us 
(now we support this too, after years of loosing customers).

tml,
thank you very much!

There is just one problem with UNC left - OpenOffice running on Win98 (WinMe) 
would not open files from XP (Win2000, WS2003), see issue 74820.

We will have problems to convince the release status committee that this fix
can't wait for another 3 months. The criteria for issues with target 2.2.1 are:
serious regression, manageable risk and limited QA effort. I doubt that this fix
fulfills the last one and it surely doesn't the first.

Hennes, I think we should change the target to 2.3. Do you agree?

Attached patch was integrated in OpenOffice 2.2 Pro, released 5th of May.
We have at least 40 000 downloads since then and no complaints in this area, 
which indicates that patch does not break anything.
Could it be integrated into master, please?

setting target 2.3

Scheduled for 2.3

Dear developers,
with just 10 days left to code freeze attached patch needs to be integrated 
ASAP.
Please state current status of this issue.
Thanks a lot.

.

The latest entry to this topic has been entered by the developer (hro)
himself/herself at 1.8.2007 and is the shortest remark in history. The text does
contain nothing more than a period-symbol. I'm just guessing:

- the developer does not want to be disturbed (involved in solving the problem).
- the developer does not want to be disturbed (reading a magazine).
- the case has been closed (problem already solved)
- the case has been closed (given up: no solution available)

A topic with 47 votes would at least be worth a sentence!
Regards -Hans-

Changed type to patch.

@kpalagin: Thx for the patch, looks good. Unfortunately I hadn't enough time to
integrate it into 2.3 - you know, it's not just changing some source code lines,
testing and quality assurance also has to be done.

@jwr: Please stop those dump offending and unqualified comments. Next time you
will be banned.

I'm not willing to comment on how I spend my time and why there wasn't enough
time to integrate this issue in 2.3.

If you had a closer look at the task, you would have seen that the target was
changed and it's neither closed nor under investigation. The log shows that the
target was changed - any need to write this in the comment too ?

Hennes,
can we integrate this patch into first build of 2.4 please?
P.S. The patch is not mine, I am just trying to push it.
P.P.S. While at it please also consider 
http://www.openoffice.org/issues/show_bug.cgi?id=74820

All,
due to popular demand I am posting links to OOo build with this patch 
integrated:

Page http://www.i-rs.ru/download

Russian language installer ftp://ftp.chg.ru/pub/OpenOffice-
RU/2.2.1/ru/OOo_2.2.1_Win32Intel_install_ru_infra_wJRE.exe

English language pack http://download.i-
rs.ru/pub/openoffice/2.2.1/ru/OOo_2.2.1_Win32Intel_langpack_en-US_infra.exe

Fixed on CWS hro24

Sorry, but not fixed in CWS hro24. Reopened.

Sorry, no time left to fix this for 2.4 => 3.0

Shall we integrate this and fix for 
http://www.openoffice.org/issues/show_bug.cgi?id=51026 as soon as possible, so 
that we do not miss 3.0?
Thanks a lot for your consideration.

WBR,
KP.

.

Fixed on CWS hro30

@tm: Please verify

*** Issue 87323 has been marked as a duplicate of this issue. ***

Sorry, no time left to integrate the fix into 3.0 code line. Last CWS
integration deadline has passed already. => 3.1

So was this patch integrated at some point?

the issue is FIXED, is it going to be integrated in OOo 3.0.1 or should we wait 
till 3.1?

Unfortunately we missed the 3.1 code freeze deadline. Bug is fixed, but
respective CWS is not approved by QA. Really don't like this, but need to 
retarget the task to 3.2. Sorry.

So could relevant CWS be integrated in, say, m45?

Is the fix for this issue already integrated in code?

Taking over... Patch applied to CWS kso32fixes.

@kso: Given that <#desc38> suggests that there never was a problem with
INetURLObject handling Windows UNC file URLs with underscores in the server name
(like <file://xxx_yyy/abc>) in the first place, I wonder whether applying the
attached accept-underscores-in-hostnames.diff patch has any real value.

This issue had disappeared from my radar a long time ago.  The attached patch is
indeed coded rather trivially (see <#desc50>), unnecessarily complicating the
code, so it should indeed have been refined.  Given how ridiculously old this
issue is, I do not want to defer a useful fix any further, but still...

sb: You are right. I missed the important fact that the patch needs to be
refined. Thanks for pointing this out. Reopening issue...

sb: Please take over.

@tm (assuming you are the appropriate Sun-internal QA person; if not, please cc
whomever else):  Can you please make sure you and I have available a suitable
test scenario, i.e., some UNC server with an underscore in its name reachable
from within Sun?  (We will both need that, anyway, to first implement and then
verify a fix.)

@sb: I will forward your request according an unc-server with an underscore in
its name to the IT-section.

 In addition to OOo not opening files located on servers which have "_" in 
their names, it also does not raise any error message when this problem 
occurs.  OOo just closes silently when that happens, leaving the user with no 
clue as to the nature of the problem.  From my employer's point of view, it 
appeared the product simply didn't work.

 If I understand you're ready to slip this fix until another release, can you 
at least try to put up some useful error message when the problem code takes 
the error path.  Thanks.

Created attachment 63459 [details]
fix

What I could reproduce with wntmsci12.pro DEV300m52 is as follows:  Given the
UNC filepath \\vm_gw3\unc_test\testdoc.odt, opening the testdoc.odt in the
Windows Explorer either opens an empty OOo writer document (in case OOo
quickstarter wass not yet running) or has no visible effect (in case OOo
quickstarter was already running).  This is consistent with command line
behavior, where

  "C:\Program Files\OpenOffice.org 3\Program\soffice" \\vm_gw3\unc_test\testdoc.odt

has the same effect (depending on whether or not OOo quickstarter was already
running), while

  "C:\Program Files\OpenOffice.org 3\Program\soffice"
file://vm_gw3/unc_test/testdoc.odt

works fine (always opening the requested document).

The reason is that when INetURLObject::convertRelToAbs smart-parses input of the
form

  "\\" domain ["\" *UCS4]

into an UNC filepath, it erroneously does not accept NetBIOS names (which allows
underscores) for the "domain" part.

The fix is the attached DEV300m52-tools.patch (containing a corresponding unit
test in tools/workben/urltest.cxx), which will be included in CWS kso32fixes
(targeting OOo 3.2).

sb: Thanks for the revised patch. I applied it on CWS kso32fixes.

@tm: please verify

checked and verified in cws kso32fixes -> OK !

Any chance to have this before 3.2 version?
Thanks a lot.

@ayacopino:  The fix got integrated into DEV300_m54.  At
<http://download.openoffice.org/>, you can either download "the most recent
OOo-Dev 3.2.0 build (codeline OOO320)" (currently OOO320_m7) or "the most recent
OOo-Dev 3.x build (codeline DEV300)" (currently DEV300_m67), both via the "Get
OpenOffice.org Developer Snapshots" link, or wait until an OOo 3.2 RC becomes
available (anytime soon now) via the "Get OpenOffice.org Release Candidates"
link.  Each of those should contain the relevant fix.

Tested in 3.2 RC1 - Win XP: the file \\XP_Test\Test\text.odt (.odt or .ods or
.doc etc) is now open, but it is impossible to save the changes because it's
locked by "unknown user".
Also in the folder \\XP_Test\Test\ the file ".~lock.Text.odt#" is not deleted
after closing the document.
No problem if I change the server name in XPTest.

 Verified the same problem reported by cantito.

 My test PC was WinXP-sp2.
 Tested using OOo_3.2.0rc1_20091217_Win32Intel_install_en-US.exe
 Tested in directory \\cccb_server\JMS-Testing

 Test1: Copied an existing Word-97 file... Testing.doc
 OOo successfully opened the doc, and created file .~lock.Testing.doc#
 When OOo closed, that lock file was not deleted.
 Next time, OOo refused to open file because it was locked by unknown user.
 Word97 opened the file OK, created it's own lock file, and deleted lock when it
closed.

 Test2: Created a new file... Testing2.odt
 OOo successfully opened the doc, and created a new lockfile
 I added text to that file and attempted to save it.
 OOo refused to write to file because it was locked by unknown user.
 I attempted to save file under a new name, and that failed with similar error.
 At end of test, lockfiles remained in directory for every file tested.

 Conclusion... Issue is Not fixed correctly in current OOo_3.2.0rc1.

Reopeneing issue according to comments above.

@mav:  Can you please verify whether the file locking code has any problems with
UNC paths with underscores in the server names, as suggested by <#desc94> and
<#desc95>.

mav->sb: Yes, I can reproduce the problem in OOo3.2 rc1.

The problem is that
INetURLObject( aURL, INET_PROT_FILE ).GetMainURL( INetURLObject::NO_DECODE )
converts "file://comp_name/path/..." to "file:///comp_name/path/..." ( just adds
slash that let the computer name be handled as a part of path.

This conversion is used in the SimpleFileAccess service implementation for long
time ( probably from the very beginning ). And the locking implementation uses
SimpleFileAccess service to manipulate the lock file from the very beginning. I
assume that any implementation that uses SimpleFileAccess is affected.

I would say that the current situation is very dangerous and should be fixed
since it is now possible to open documents on such locations. Thus the
probability of remaining lock file after unsuccessful saving is very high.

fixed that problem as tools/source/fsys/urlobj.cxx#277881 and
tools/workben/urltest.cxx#277881 on SVN CWS fwk135

Reassigned to TM.

Verified in CWS fwk135.
SBA->TM: As discussed, please re-verify after integration of CWS into master and
close.

Ok, now works fine!
thanks!

 I agree, it works now.  Thanks.

 Used OOo_3.2.0rc2_20100111_Win32Intel_install_wJRE_en-US.exe
 Tested both with and without Quickstart running.