Download it now!
Bug 53288 - UNC path handling issue in config handling
Summary: UNC path handling issue in config handling
Status: RESOLVED DUPLICATE of bug 50542
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
3.6.0.4 release
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
Depends on:
Blocks:
 
Reported: 2012-08-09 11:20 UTC by Andreas Berger
Modified: 2014-11-06 21:07 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Berger 2012-08-09 11:20:11 UTC
Problem description:

Unable to use spellchecking as a regular user on Windows 7 and Windows 2008R2

Steps to reproduce:
1. Install LibreOffice 3.6 with default settings, as a user with Admin rights.
2. Log in as a user that is only member of the local users group.
3. Open LibreOffice and start typing misspelled words in a document. Spellcheck will not work.
4. Check Settings -> Language, no module for hunspell can be found.
5. Log in as an Admin user and step 3 will work as expected.

Current behavior:

Spellcheck does not work unless member of local administrators group

Expected behavior:

Even restricted users should be able to use spellcheck

Platform (if different from the browser): 
              
Windows 7 x64 as well Windows 2008R2
Comment 1 Andreas Berger 2012-08-09 12:33:14 UTC
I've done some additional testing, and it appears to occur when using folder redirection. I don't know if this is the same as, or at least related to https://bugs.freedesktop.org/show_bug.cgi?id=52336 and/or https://bugs.freedesktop.org/show_bug.cgi?id=36558

Also, when using redirected folders it takes several minutes to actually start LibreOffice. This is regardless if the profile is brand new or already existing.
Comment 2 Julien Nabet 2012-08-15 20:58:08 UTC
Confirmed on IRC by "ThinkGNU-" on WinXP so put the tracker to NEW
Comment 3 Julien Nabet 2012-08-15 20:59:33 UTC
sorry, bug confirmed + info that new LO profile solves the bug.
Comment 4 Stephan Bergmann 2012-08-16 06:44:36 UTC
(In reply to comment #1)
> I've done some additional testing, and it appears to occur when using folder
> redirection. I don't know if this is the same as, or at least related to
> https://bugs.freedesktop.org/show_bug.cgi?id=52336 and/or
> https://bugs.freedesktop.org/show_bug.cgi?id=36558

From the original description, this sounds very much like the "Various problems with bundled extensions" of <https://wiki.documentfoundation.org/ReleaseNotes/3.6#Most_annoying_bugs>; see the workaround there (remove part of LibreOffice's per-user data).

(It might be that in your case, LibreOffice had never been started for the given Admin user before, so that there was no old, problematic per-user data for that user, so it just looked like it works for Admin users but not for normal ones.)

> Also, when using redirected folders it takes several minutes to actually start
> LibreOffice. This is regardless if the profile is brand new or already
> existing.

See bug 53009 for the long first-start times.

*** This bug has been marked as a duplicate of bug 53006 ***
Comment 5 Andreas Berger 2012-08-16 07:27:58 UTC
No matter if I remove the extensions dir, or let LO 3.6 create an entirely new profile, spellcheck will not work. 

I'm not sure I understand the specifics of https://bugs.freedesktop.org/show_bug.cgi?id=53006 but since this is marked a duplicate of that bug, I guess this will all get solved with LO 3.6.1 then.
Comment 6 Stephan Bergmann 2012-08-16 07:36:21 UTC
(In reply to comment #5)
> No matter if I remove the extensions dir, or let LO 3.6 create an entirely new
> profile, spellcheck will not work. 

OK, that makes it unlikely to be due to the same root cause as bug 53006, then.  So back to REOPENED for now.

What do you mean with "folder redirection"?
Comment 7 Andreas Berger 2012-08-16 09:06:43 UTC
Folder redirection is where instead of having all the users data in a local profile, you redirect say %APPDATA% to another network storage. So instead of the appdata being stored in C:\users\user\appdata\roaming\ it's somewhere like \\server\share$\appdata_roaming\user\. We do this to make user profiles consistent across an RDS cluster among other things. See http://technet.microsoft.com/en-us/library/cc732275.aspx

Pretty much like if you'd mount /home over an NFS share in a Linux environment, except it's for select folder and not the entire profile. Difference is that in Linux the system would still act as if the mountpoint was /home/user, and on Windows it prints the full path to the share instead of "mounting" it in the local user-profile.

Since recreating a userprofile for a user with his profile stored locally makes spellcheck work, is why I'm wondering if it might be related to the bugs I mentioned in https://bugs.freedesktop.org/show_bug.cgi?id=53288#c1
Comment 8 Urmas 2012-08-16 09:24:15 UTC
Strange, I just moved AppData folder to a network share, and spellchecking works. What else can be here?
Comment 9 Stephan Bergmann 2012-08-16 09:28:17 UTC
(In reply to comment #5)
> I guess this will all get solved with LO 3.6.1 then.

Reportedly, LO 3.6.1 test builds start to appear at <http://dev-builds.libreoffice.org/pre-releases/> now.  Would be great if you could check whether it makes any difference for this problem.
Comment 10 Andreas Berger 2012-08-16 13:20:58 UTC
(In reply to comment #9)
> (In reply to comment #5)
> > I guess this will all get solved with LO 3.6.1 then.
> 
> Reportedly, LO 3.6.1 test builds start to appear at
> <http://dev-builds.libreoffice.org/pre-releases/> now.  Would be great if you
> could check whether it makes any difference for this problem.

Unfortunately not, I've tried deleting ..\extensions and restarting LO a bunch of times, as well as deleting the entire profile and doing the same. It will seemingly create the profile every time, it just won't enable spellcheck for any language.

Is there a simple way to launch LO with a specific path to the profile dir? In that case I could do some trial and error with regards to where it's located.
Comment 11 Stephan Bergmann 2012-08-16 13:31:50 UTC
(In reply to comment #10)
> > Reportedly, LO 3.6.1 test builds start to appear at
> > <http://dev-builds.libreoffice.org/pre-releases/> now.  Would be great if you
> > could check whether it makes any difference for this problem.
> 
> Unfortunately not, I've tried deleting ..\extensions and restarting LO a bunch
> of times, as well as deleting the entire profile and doing the same.

You did that with 3.6.0 or with 3.6.1?  (Not that it would probably make much difference, though...)

> It will seemingly create the profile every time.

Yes, both the whole user\... tree as well as just the user\extensions\... tree will be automatically created when not there at start up of LO.

> Is there a simple way to launch LO with a specific path to the profile dir? In
> that case I could do some trial and error with regards to where it's located.

You can run soffice with a -env:UserInstallation=file:///C:/foo command-line argument to have the profile created in C:\foo, say.  The only gotcha is that the argument indeed needs to be a a file URL (i.e., forward slashes, "%20" instead of a blank, etc.)
Comment 12 Andreas Berger 2012-08-29 10:59:25 UTC
My problems with regards to speed is due to some misconfiguration with the share, so it can be disregarded. Running LO with a local profile as described in comment11 will run the app at normal speeds. 

Running LO with a profile in say C:\Temp\testuser results in me having access to spellcheck (hunspell).

I tried pointing LO to a mapped network share, the users homefolder "W:\lo-test\" and here spellcheck also works.

When folder redirection is being used, it's shown as a UNC path. E.g \\fileserver\appdata$\user\AppData\Roaming\LibreOffice\3\user\*

Could this be the real issue?
Comment 13 Stephan Bergmann 2012-08-29 11:51:30 UTC
this sounds related to bug 50542, btw
Comment 14 Andreas Berger 2012-09-03 09:53:44 UTC
Yep, it seems it would be related to https://bugs.freedesktop.org/show_bug.cgi?id=50542

What I did to work around the problem was to mount %APPDATA% as X: (hidden) and then edit bootstrap.ini to use the mounted path for the profile instead. Now everything works as expected.
Comment 15 Michael Meeks 2012-10-08 13:01:14 UTC
So - re-titling to better reflect the bug; it seems to me most likely to be a duplicate of bug#50542 - can someone confirm and mark it thus ? Either way it doesn't -appear- to be related to upgrading / migration - so dropping the migration tracker bug dependency.

Hope that's ok :-)
Comment 16 cpohle 2012-10-10 13:11:53 UTC
According to my obeservations, it might well be a duplicate. Spellcheck does not work for users with roaming profiles (WinXP).
Comment 17 Serge 2012-11-06 08:28:57 UTC
Hi,

it seams that this bug is the same that I can recreate on our network:
Bug 55138 and 56775

As mentionned above the path to the server is \\server\share$. LO answers the \\server\share does not exist (which is correct) as the path ends with the $ sign (hidden share on windows)
Comment 18 Stephan Bergmann 2012-11-06 08:33:32 UTC
(In reply to comment #17)
> Hi,
> 
> it seams that this bug is the same that I can recreate on our network:
> Bug 55138 and 56775

yes, and your description of bug 56775 made me finally realize what the root problem probably is; investigating
Comment 19 Joel Madero 2014-11-06 21:07:58 UTC
Closing as a dupe - if this is incorrect please set to NEW and not REOPENED. Thanks all.

*** This bug has been marked as a duplicate of bug 50542 ***