> For reference, OpenOffice 3.3 has exactly the same issue.

Issue report for OOo:

http://www.openoffice.org/issues/show_bug.cgi?id=115778

Tor, any idea what could be the problem?

I quote from the OOo issue: "It looks like a problem related to the
UNC path used for the user profile within the deployment library which is
responsible for extensions."

*** Bug 32135 has been marked as a duplicate of this bug. ***

I can confirm this bug (WinXP Pro SP3). Everything works nice when using a local sysadmin profile, however usage of a roaming profile triggers the two exceptions listed above. The issue persists in LibO 3.3.1 RC1.

Having reviewed the list of other blocker and critical LO bugs, I've raised this issue's importance.

On a related note, the equivalent OOo bug has been marked to be fixed by OOo 3.4.

It would be nice if we could fix this in 3.3.2. Does anybody know a way to reproduce it on a non-domain-member machine?

Tor, not sure about that, but here's an alternate approach: teach me to build the source from git for the Windows platform.  Assuming the issue was introduced sometime during LibreOffice's lifetime, I could bisect to the offending commit.

Or, build me the first revision from git and I'll try it.

Right now I cannot find any build-for-Windows instructions on libreoffice's site.

http://wiki.documentfoundation.org/Development/Windows_Build_Dependencies and http://wiki.documentfoundation.org/Development/How_to_build should get you started. Then come to the IRC channel #libreoffice on freennode, or ask specific questions on the libreoffice mailing list. We very much want to help people in learning to build it!

I have done some testing with the following betas of LibO 3.3:
- beta 1 (2010-09-27, OOo330m7, Build 9526, OOo-build 2010-09-24)
- beta 2 (2010-10-11, OOo330m9, Build 1, libreoffice-build 3.2.99.2)
- beta 3 (2010-11-15, OOo330m12, Build 2, libreoffice-build 3.2.99.3)

All of them start-up normally in a local user context but produce the errors described above when used with roaming profiles. In addition, beta 1 sometimes gave the following error:

The application cannot be started
A general error occurred while accessing your central configuration

To me this suggests that this bug was probably introduced before the OOo/LibO fork, which would be in line with OOo330 facing the same problem.

This bug still exists in LibreOffice 3.3.1 RC2 (2011-02-18). This is sad that it existed in 3.3 final release. It is very disturbing that it exists in RC2 for another release. I am happy to test out nightlies or what not. I have several domains with XP SP3, Vista (latest SP) and 7 (latest).

I would help with the code/build, but it has been ages since I had MSVC setup on any machines and used it.

No need to point out that the bug has not been fixed; if it had, we (developers) would have marked it as fixed here.

Nobody can figure out a way to reproduce the problem on a non-domain-member machine (but with other Windows machines in the same workgroup, if needed)? That would obviously be very useful so that this can be debugged.

Due to the fact that the bug seems to be with roaming profiles, I am not sure you can reproduce it any other way. I am using Samba 4 for the server if that is the problem. If it is because you don't have Pro/Business/Enterprise/Ultimate clients, I am not sure how to go about doing it.

Many of the people who would be interested and capable of debugging this, including me, have access to MSDN, so if really really necessary, sure, I can set up a domain between two virtual machines. It's just a pain to do just for some debugging of what no doubt turns out to be a very easy to fix error once you find the root cause.

Hmm, actually, I might have a domain set up in a vmware virtual machine running Windows Server 2003 I haven't started for ages, will have to check. I could then set up roaming progiles, however one does that (I don't have any Windows domain sysadmin experience), and join another virtual machine to that domain, and debug LibreOffice on that. But that will have to wait until I get back from vacation next week.

LibreOffice 3.3.0 and 3.3.1 gets fatal error if %appdata% is redirected.
Also happens with OpenOffice 3.3.

Only happens if the user never started LibreOffice before %appdata% was
redirected, the user has no problems if LibreOffice was started before %appdata%
was redirected.
Seems like the problem lies in %appdata%\LibreOffice.

I have tried to rename %appdata%\LibreOffice on a user that LibreOffice was
working for (did use LibreOffice before %appdata% was redirected), then
LibreOffice generated it again and Fatal error.
Put back the working %appdata%\LibreOffice folder and everything works.

Have tested this on Windows 2003 and 2008 R2 terminal servers.

*** Bug 34817 has been marked as a duplicate of this bug. ***

(In reply to comment #15)
> LibreOffice 3.3.0 and 3.3.1 gets fatal error if %appdata% is redirected.

I can confirm this. I changed the group policy to redirect Application Data back to the user's profile (while leaving all other redirections in place), and the problem is solved.

So, on a machine that is not a member of a domain, to reproduce the problem, it is enough to set the APPDATA environment variable to a UNC path before starting LibreOffice the first time?

just run into this bug on linux after upgrading from 3.3.0 to 3.3.1...

something is wrong with my config in .libreoffice may be some locking problem?

this suprisingly solved it for me:

mv ~/.libreoffice ~/.libreoffice.xxx
cp -vax ~/.libreoffice.xxx ~/.libreoffice

sounds and looks stupid but it now works again 8)

i also tried moving it back:

rm ~/.libreoffice
mv ~/.libreoffice.xxx ~/.libreoffice

and it stopped working again..

my home is on a NFS3 Server so i suggest some locking problem but i don't have the time right now for further investigation..(like tracing NFS traffic or removing files one by one from .libreoffice) ..but i still have my ~/.libreoffice.xxx to test again later..

i am using a linux from scratch based distribution with kernel 2.6.35.10 and glibc 2.12.1.. arch=x86_64.. libreoffice is installed using the rpms for 64bit linux downloaded from the official website..

may be this information helps solving this bug.. i can provide more information if needed later..

bye.. marius tolzmann..

i forgot to mention that the problem still existed after downgrading to 3.3.0 again..

Marius, whatever problem you have on Linux, it has nothing at all to do with what this bug report is about. This bug report is about a Windows-specific issue. Please file a separate bug.

Pål, when you say "LibreOffice 3.3.0 and 3.3.1 gets fatal error if %appdata% is redirected" what do you mean exactly? (I asked the same question to you in the OOo issue, see details there...)

I would very much like to fix this, but first I need to reproduce it, on a machine that is not a member of a domain.

It's interesting that even if I set an APPDATA environment variable in Control Panel:System:Advanced:Environment Variables, if I then run cmd.exe, it still has the normal value for APPDATA (C:\Documents and Setings\N.N\Application Data , on XP). So is APPDATA treated specially, does cmd.exe override any setting of it in its environment? Does explorer.exe ignore attempts to set APPDATA?

If nobody can come up with a way to reproduce this in a non-domain-member machine, could somebody at least give *exact* instructions how to set up "roaming profiles" and "redirected folders" when I have a Windows Server 2008 R2 running with the Active Directory Domain Services role activated, and have joined a XP workstation to that domain. (Both are virtual machines, and yes, I can ping one from the other.)

If you want this problem fixed, please at least help me to reproduce it! You who have the problem, can't you ask your sysadmin to write here a step-by-step guide how to set up a minimal temporary test domain with "roaming profiles" and "redirected folders", huh? Or are you attempting to use LibreOffice without the sysadmins knowing?

This is from a windows XP perspective. I do not have the updated instructions in front of me:

Click Start, point to Programs, point to Administrative Tools (Common), and then click User Manager for Domains or Active Directory Users and Computers
Select all relevant users, right-click one of the users, and then click Properties.
Click on Profile
User Profile Path type “\\SERVER_NAME\profiles\%USERNAME%” in the box, and then click OK. 
User Home Path type “\\SERVER_NAME\homes\%USERNAME%” in the box, and drive letter and then click OK. 
Right click on domain, do new GPO for full domain
1. User Configuration/Folder Redirection/My Documents to drive letter

Default Policy/User Configuration/Windows Settings/Folder Redirection/AppData
Basic
Create a folder for each user under the root path
\\%FILESERVER%.%DOMAIN\appdata
Settings: Grant user exclusive, move contents, also apply to 2000, XP, etc., leave when deleted
Default Domain GPO "Exclude Directories in roaming profile"

appdata is a share I setup, btw.

Thanks. There were indeed a couple of points there that I wouldn't have realized myself. Will try that out tomorrow. If anybody else has more hints, please add comments!

Sorry, forgot a few others %FILESERVER%.%DOMAIN are not real variables. They are just my way of remembering in my own instructions. %USERNAME% is a real one.

In WS2008R2, the "Profile" tab of the domain user properties has one entry box for "Profile path", so that should be \\%server%\profiles\%username% as you say in comment #25 then, OK. (Where %server% and %username% are replaced with the actual server and user names.) This is fairly clear.

Do I need to create this "profiles" share on the server beforehand, and set its owner to the domain user in question? Or is "profiles" some kind of "magical" share name?

But then about the "Home  folder", it is not so clear. There are two alternatives here, "Local path" and "Connect" (connect a drive letter to what I assume should be a UNC path). You mean I should use the latter alternative? Should I then create the "homes" share you mention and a subdirectory for the user under it, or will it be created automatically when the user logs in to a domain member?

I already yesterday had entered into "Profile path" a UNC path to a directory for the user I had created on the server (and left the "Home folder" entries empty), but when I logged in on the domain member machine, it complained it couldn't connect to the profile folder, or something like that. I guess I should try to figure out that first, or will filling in the "Home folder" stuff automatically make that work OK, too?

Thanks in advance for any further advice...

I think my current problem now is firstly to make it possible for the XP domain member to see and mount shares on the ws2008r2 server... that seems to require some extra trick I haven't figure out yet, I just get error 5 if I try "net view \\server" or "net use \\server\scratch x: /user:foo" where scratch is a share I made as wide-open as possible, and foo is a domain user. Hmm....

The homes share is a share I created. For me (XP, Vista, 7) it auto-creates the path for the user when you set it up, but you do have to create the share. And yes, I meant where you connect a drive letter to a UNC.

Profiles I think is magic if you are using Windows, but I do NOT know that. I have to set it up manually as I am using Samba 4. (http://wiki.samba.org/index.php/Samba4/HOWTO may or may not help as it is where I got a lot of the information, or at least where I started from.)

If you setup the paths correctly and they point to valid shares, then everything should automatically work. At least it does here for me.

OK, after explicitly creating the appdata\%username%, homes\%username% and profile\%username% folders on the server and making sure that user has max permissions to them and is their owner I think I got it working to some extent. At least I now can log in to the client without warnings.

But the AppData is still not redirected, I still see the LibreOffice folder being created in the XP client locally in C:\Documents and Settings\%username%\Application Data .

Maybe I really need to set up a Windows 7 client? (Unfortunately the one Windows 7 virtual machine I already have is in Chinese (I once wanted to check how something worked in a Chinese localisation...), and that is a bit hard to use...)

Ok, I think you must have failed to setup a GPO that applies to the user in question (mine are all domain wide at this time).

In group policy editor do the following (some things may be different if you are setting things up on Windows Vista/7 vs XP, so if the client is XP, do it there, also some locations may be correct for Vista/7, others for XP so you may have to search a bit):

Default Policy/User Configuration/Windows Settings/Folder Redirection/AppData
Basic
Create a folder for each user under the root path
\\%FILESERVER%.%DOMAIN\appdata
Settings: Grant user exclusive, move contents, also apply to 2000, XP, etc.,
leave when deleted
Default Domain GPO "Exclude Directories in roaming profile"

I think on the local machine it may show things still being in that directory as some of them are remapped, the question is to see if it exists in appdata\%USERNAME% on the server.

Check the APPDATA environment variable as well, see if it changed.

(In reply to comment #22)
> Pål, when you say "LibreOffice 3.3.0 and 3.3.1 gets fatal error if %appdata% is
> redirected" what do you mean exactly? (I asked the same question to you in the
> OOo issue, see details there...)
> 
> I would very much like to fix this, but first I need to reproduce it, on a
> machine that is not a member of a domain.

I have replied in the OOo issue but I reply here too.

I mean I have used Group Policy in Windows Active Directory Domain to create a
policy that redirects everyone's appdata folder to the same location, also
called roaming.

The reason I do this is that we have terminal servers at work and a lot of data
is stored at appdata, if we did not redirect appdata it would be copied to the
terminal server every time they logon witch give a longer logontime.

This is how I have set up the redirect policy.
Windows server 2008 R2 -> Group Policy Management -> New Policy -> User
configuration\Policies\Windows Settings\Folder Redirection\AppData(Roaming):

Target:
Setting = Basic - Redirect everyone's folder to the same location.
Target folder location = Create a folder for each user under the root path.
Root path = \\server\users

Settings (enabled):
On - Move the contents of AppData(Roaming) to the new location.
On - Also apply redirection policy to Windows 2000, Windows 2000 Server,
Windows XP, and Windows Server 2003 operating systems.
On - Leave the folder in the new location when policy is removed.


Ex. For user Clair, this folder will be redirected to:
\\server\users\Clair\Application data

Pål, ok, so you use the normal \users folder on the server for the redirected app data. Should it be possible to reproduce the problem using *only* the redirected app data folder like that (and \users then shared, presumably)? I.e. redirection of "documents" is not needed, nor is it needed to set up separate homes, profiles or appdata shares? What do you do for profiles, do you set up anything in the "Profile" tab of the domain user properties?

I prefer to have an as minimal way as possible to reproduce the problem.

(In reply to comment #35)
> Pål, ok, so you use the normal \users folder on the server for the redirected
> app data. Should it be possible to reproduce the problem using *only* the
> redirected app data folder like that (and \users then shared, presumably)? I.e.
> redirection of "documents" is not needed, nor is it needed to set up separate
> homes, profiles or appdata shares? What do you do for profiles, do you set up
> anything in the "Profile" tab of the domain user properties?
> 
> I prefer to have an as minimal way as possible to reproduce the problem.

When you say the normal \users folder on the server do you think of C:\Users?
If so I do not use the normal users folder on the server.

I have created a personal home folder for every user, lets call it homes instead of users. This folder is then shared and every user has it's own personal folder in here for personal stuff that only that person and domain admins has access to.

AppData(Roaming) Target Root path = \\server\homes

Ex. For user Clair, this folder will be redirected to:
\\server\homes\Clair\Application data

I also redirect Desktop, Documents, Pictures, Music and Videos folders to \\server\homes, but this should not have anything to do with LibreOffice/OOo error!

The only thing I do in the "Profile" tab of the user properties is:
Home folder, Connect = H: to \\server\homes\%username%

The User profile, Profile path is blank!

OK, thanks. I was misunderstanding your comment #34.

This seems to be fixed in the Oracle OO 3.4 alpha that has just been released
Is the plan to try and fix this for 3.3.3 or 3.4. As a XP site with 500+
machines this bug is a complete show stopper. :-(

M

Great, will have to look how they fixed it then and see if it can easily be adapted to 3.3 (as we presumably will continue releasing new 3.3.x versions once a month or so). But in any case the fix will naturally then be in our 3.4, too. We merge in OOo changes in LibreOffice in general.

*** Bug 35583 has been marked as a duplicate of this bug. ***

I see no mention in the OOo issue (http://openoffice.org/bugzilla/show_bug.cgi?id=115778 ) that it would have been fixed intentionally.

*** Bug 35583 has been marked as a duplicate of this bug. ***

Looks like the problem is solved in OpenOffice.org 3.4 Alpha Release (build
DEV300m101). I have tested it and the problem did not occur.

I'm also hitting this bug.

If this helps testing:

If you follow these steps, it will also fail:
 * create a new local account
 * Log in with the new account
 * change HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders\AppData to REG_EXPAND_SZ with value C:\test-appdata (or whatever)
 * Create the folder C:\test-appdata and if necessary give permissions to the new local account
 * Log out and log in again
 * Start a command prompt and verify the content of %APPDATA% (echo %APPDATA%)
 * Start LibreOffice

This is what the group policy object changes under the hood.

Wilco, thanks a lot! I didn't try yet but your instructions sound very promising.

Wilco, using c:\test-appdata for that Registry value I had no problem starting LibreOffice.

But if I use a UNC path (in my case, \\vmware-host\Shared Folders\tmp\test-appdata) I can indeed reproduce the problem. Yay, finally!

Wilco, thanks once more. This kind of trivial way to reproduce the problem was what I was asking for already in comment #7.

Debugging this now; in case I get interrupted, here is the stack trace at an interesting spot, and some musings:

>	deploymentmi.uno.dll!dp_registry::backend::BackendDb::getDocument()  Line 95	C++
 	deploymentmi.uno.dll!dp_registry::backend::configuration::ConfigurationBackendDb::getAllDataUrls()  Line 144 + 0xf bytes	C++
 	deploymentmi.uno.dll!dp_registry::backend::configuration::`anonymous namespace'::BackendImpl::BackendImpl(const com::sun::star::uno::Sequence<com::sun::star::uno::Any> & args=0x00e9f408 {size=0x00000003}, const com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> & xComponentContext={...})  Line 216 + 0x16 bytes	C++
 	deploymentmi.uno.dll!cppu::ImplInheritanceHelper1<dp_registry::backend::configuration::`anonymous namespace'::BackendImpl,com::sun::star::lang::XServiceInfo>::ImplInheritanceHelper1<dp_registry::backend::configuration::`anonymous namespace'::BackendImpl,com::sun::star::lang::XServiceInfo><com::sun::star::uno::Sequence<com::sun::star::uno::Any>,com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> >(const com::sun::star::uno::Sequence<com::sun::star::uno::Any> & arg1=0x00e9f408 {size=0x00000003}, const com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> & arg2={...})  Line 187 + 0x36 bytes	C++
 	deploymentmi.uno.dll!comphelper::service_decl::detail::OwnServiceImpl<cppu::ImplInheritanceHelper1<dp_registry::backend::configuration::`anonymous namespace'::BackendImpl,com::sun::star::lang::XServiceInfo> >::OwnServiceImpl<cppu::ImplInheritanceHelper1<dp_registry::backend::configuration::`anonymous namespace'::BackendImpl,com::sun::star::lang::XServiceInfo> >(const comphelper::service_decl::ServiceDecl & rServiceDecl={...}, const com::sun::star::uno::Sequence<com::sun::star::uno::Any> & args=0x00e9f408 {size=0x00000003}, const com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> & xContext={...})  Line 182 + 0x36 bytes	C++
 	deploymentmi.uno.dll!comphelper::service_decl::detail::ServiceImpl<dp_registry::backend::configuration::`anonymous namespace'::BackendImpl>::ServiceImpl<dp_registry::backend::configuration::`anonymous namespace'::BackendImpl>(const comphelper::service_decl::ServiceDecl & rServiceDecl={...}, const com::sun::star::uno::Sequence<com::sun::star::uno::Any> & args=0x00e9f408 {size=0x00000003}, const com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> & xContext={...})  Line 211 + 0x3a bytes	C++
 	deploymentmi.uno.dll!comphelper::service_decl::detail::CreateFunc<comphelper::service_decl::detail::ServiceImpl<dp_registry::backend::configuration::`anonymous namespace'::BackendImpl>,comphelper::service_decl::detail::PostProcessDefault<comphelper::service_decl::detail::ServiceImpl<dp_registry::backend::configuration::`anonymous namespace'::BackendImpl> >,comphelper::service_decl::with_args<1> >::operator()(const comphelper::service_decl::ServiceDecl & rServiceDecl={...}, const com::sun::star::uno::Sequence<com::sun::star::uno::Any> & args=0x00e9f408 {size=0x00000003}, const com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> & xContext={...})  Line 263 + 0x31 bytes	C++
 	deploymentmi.uno.dll!boost::detail::function::function_obj_invoker3<comphelper::service_decl::detail::CreateFunc<comphelper::service_decl::detail::ServiceImpl<dp_registry::backend::configuration::`anonymous namespace'::BackendImpl>,comphelper::service_decl::detail::PostProcessDefault<comphelper::service_decl::detail::ServiceImpl<dp_registry::backend::configuration::`anonymous namespace'::BackendImpl> >,comphelper::service_decl::with_args<1> >,com::sun::star::uno::Reference<com::sun::star::uno::XInterface>,comphelper::service_decl::ServiceDecl const &,com::sun::star::uno::Sequence<com::sun::star::uno::Any> const &,com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const &>::invoke(boost::detail::function::function_buffer & function_obj_ptr={...}, const comphelper::service_decl::ServiceDecl & a0={...}, const com::sun::star::uno::Sequence<com::sun::star::uno::Any> & a1=0x00e9f408 {size=0x00000003}, const com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> & a2={...})  Line 131 + 0x18 bytes	C++
 	comphelp4MSC.dll!00edf63a() 	
 	[Frames below may be incorrect and/or missing, no symbols loaded for comphelp4MSC.dll]	
 	comphelp4MSC.dll!00edf6df() 	
 	cppuhelper3MSC.dll!00370c0c() 	

The m_urlDb at that top of the stack location is "file://vmware-host/Shared%20Folders/tmp/test-appdata/LibreOffice/3/user/uno_packages/cache/registry/com.sun.star.comp.deployment.configuration.PackageRegistryBackend/backenddb.xml" which IMHO is bogus. UNC paths should not be represented as file: URLs where the host part is the server name. More correct would be "file://///vmware-host/Shared%20Folders/..." IMHO. But as such, as long as the conversion from an UNC path to an URL and back results in the same UNC path as it started with, it shouldn't be a problem if the file: URL for the UNC path is bogus. But does it? Debugging...

Yeah, I am fairly sure I understand the problem now. It is basically a mismatch between how OOo/LO represents UNC paths as URLs format, and what libxml2 is prepared to handle.

The correct syntax for file: URLs on Windows is severely under-specified. Historically even for local file names various incompatible formats have been used, like Mozilla (Netscape?) at some point using | instead of :.

But by now, I think the form generally agreed upon for local file names, at least when ASCII only is involved (yeah... a big "only") is file:///x:/rest/of/path , where x: is the drive letter.

For UNC paths there is much less consensus. OOo/LO uses the form file://server/share/rest/of/path . But libxml2 does not handle that. Look at the code in xmlIO.c:xmlNoNetExists().

Now, this bug would have been *much* easier to solve if only the error handling would have been saner. In unoxml/source/dom/documenthandler.cxx:warning_func(), the nice verbose error message from libxml2 is used, we get 

libxml2 warning
failed to load external entity "file://vmware-host/Shared%20Folders/tmp/test-appdata/LibreOffice/3/user/uno_packages/cache/registry/com.sun.star.comp.deployment.configuration.PackageRegistryBackend/backenddb.xml"

And then in throwEx() in the same file we still have that message around, and it is stored in a com::sun::star::xml::sax::SAXParseException, which is thrown. 
But that exception is then caught in desktop/source/deployment/manager/dp_manager.cxx:dp_manager::PackageManagerImpl::create() with just:

    catch (Exception &) { ... }

How nice. If the actual exception object would be captured here, we would see that it contains a nice verbose message "Extension Manager: failed to read data entry in configuration backend db: file://vmware-host/Shared%20Folders/tmp/test-appdata/LibreOffice/3/user/uno_packages/cache/registry/com.sun.star.comp." Yes, the URL is truncated (!), but still, showing that to the user would have been more useful than just saying "caught unexpected exception".

This problem has been fixed in OOo 3.4 as a side-effect of them fixing their issue http://openoffice.org/bugzilla/show_bug.cgi?id=109096 , in CWS jl164. Cherry-picking just the lines that help this problem is trivial. Will commit to the libreoffice-3-3 branch after I get one approval. (We presumably don't want to cherry-pick all of that CWS to our 3.3 branch, even if it fixes other symptoms of the same basic problem, too. But so far nobody seems to have reported the other symptoms for us, so maybe they are rare.)

Patch:

--- desktop/source/deployment/registry/dp_backenddb.cxx
+++ desktop/source/deployment/registry/dp_backenddb.cxx
@@ -92,7 +92,10 @@ css::uno::Reference<css::xml::dom::XDocument> BackendDb::getDocument()
         ::osl::File::RC err = ::osl::DirectoryItem::get(m_urlDb, item);
         if (err == ::osl::File::E_None)
         {
-            m_doc = xDocBuilder->parseURI(m_urlDb);
+            ::ucbhelper::Content descContent(
+                m_urlDb, css::uno::Reference<css::ucb::XCommandEnvironment>());
+            Reference<css::io::XInputStream> xIn = descContent.openStream();
+            m_doc = xDocBuilder->parse(xIn);
         }
         else if (err == ::osl::File::E_NOENT)
         {

+1 for 3.3 from me

Fixed now in the 3.3 branch. (In master also fixed as part of the merge of OOo DEV300 stuff.)

Nearly fixed. I built an XP pro SP3 machine from scratch
Installed LO 3.4 B5 syspreped the machines and imaged it.
Then downloaded the image to another machine. The first 
user ( with a redirected home / application data /etc )
to log in got the '[context=user]' error. Subsequent launches
of LO by that user worked and all other users also worked
afterwards

M