Bug 36047

Tor, I have the impression you had some fix for something similar.

Hello,

I did some additional experiments to try to get the scheduler working again. I tried to run scalc from the command line:

C:\Users\Paul>"C:\Program Files (x86)\LibreOffice 3\program\scalc.exe" -o "\\bra
voxps2\Projects\Administratie Piak\Maand schemas\2011\Paul\Paul urenadministrati
e 2011.xls"

This briefly flashes the splash screen

C:\Users\Paul>"C:\Program Files (x86)\LibreOffice 3\program\scalc.exe" -o "\\bra
voxps2\Projects\Administratie Piak\Maand schemas\2011\Paul\Paul_urenadministrati
e_2011.xls"

This works.
The problem occurs only with spaces in the file name, spaces in the directory path are no problem.

I hope this helps

Paul

Hello,

This problem gets really weird. Now I cannot open the file with underscores by double clicking any more. It seems the spaces are not the problem after all.

When I modify the file name (make it one character longer, shorter or even just modify a single character), I can open the document by double clicking in the windows explorer. When I change the filename back to the original name, I only briefly get the splash screen and a silent crash. It is the same file every time,I only rename the file.

The copies of the document with different names (replaced spaces by '_' and one copy named xxx.xls) I made a few days ago (which worked then) now also don't work any more. A new copy of those documents does work.

Selecting open with... also doesn't start scalc.exe
When I choose to open with another program (notepad++) everything is fine, so there is no network access problem.
Note that this seems to happen only when trying to open this document from a network share like: "\\bravoxps2\long path\file.xls"


Best regards,

Paul van der Hulst

Could you please try with the 3.4 beta2, from http://dev-builds.libreoffice.org/daily/Windows_Release_Configuration/libreoffice-3-4/20110420/ ?

(Note that the "daily" in the URL is so far just wishful thinking, at least for Windows; the builds are done and uploaded manually, one of the two people that hopefully know how to do these builds is on vacation, and for the other (me) there is a long weekend (public holiday both Friday and Monday) coming, so there certainly won't be any new, "nightly" or otherwise, Windows build before next week.)

(Yes, we know the beta2 has other serious problems still. Just test the very thing this bug report is about, thanks. Do feel free to report other problems in separate bug reports, though. But we do know about the crash on exit and the localisation problems.)

Let me add that I could not reproduce the problem with LibreOffice 3.3.2 or a 3.4 build. I was able to open a spreadsheet document at the path

\\vmware-host\Shared Folders\tmp\foo bar zap.xls

just fine. Also if I renamed it to "foo bar_zap.xls" or "foo_bar_zap.xls".

Hello,

As described, 'new' documents (copied from the faulty ones) or renamed documents do not have the problem at first. For some unknown reason the problem appears after some time for specific file names. The copies that worked last week stopped working this week.

I tried the DEV300m103 (Build:1) version of libreoffice 3.4.0. It has the same problem.

Paul

Just for the future: Identifying LibreOffice builds using the information from the current Help:About dialog, like the "DEV300m103 (Build:1)" in the previous comment, is useless.

That isn't enough to separate one build from another, unfortunately. The "Build" number is mostly useless, at least for beta and nightly builds (if we had such), and especially for rush jobs like 3.4 beta 2 which was (as far as I know) an incremental rebuild of the beta 1 done quickly without waiting for the actual tagging of beta 2, to get out a fix for the horrible problems in 3.4 beta 1 before the upcoming religious holiday/vacation period. Yes, we know this is a mess.

The only reliable way to identify a build is by telling the exact file name of the installer. At least so far we have managed to keep those unique.

Just to confirm, that would be LibO_3.4.0beta2_Win_x86_install_multi.exe then, as you suggested.

PAul

So do you have some sample documents that cause the problem? Please attach such a sample document here (after removing any confidential information from it, obviously).

Assigning back to list, little I can do for now.

The problem is that when I make a copy of the document, that copy works fine, until I try to open it again some days later, then it will fail to start libreoffice.

As you will have noticed, I edited the title since the spaces do not seem to be the problem. 

The problem is probably not even in the file, since when I access the file through a different path
\\BRAVOXPS2\Administratie Piak\Maand schemas\2011\Paul
vs
\\BRAVOXPS2\Projects\Administratie Piak\Maand schemas\2011\Paul
double-clicking the file will successfully start libreoffice.

Note that the file is located on a different computer \\BRAVOXPS2
A copy on my own computer is located in c:\Projects\Administratie Piak\Maand schemas\2011\Paul
This copy works fine when opening locally (from c:) When I try to access it through a network share \\ALPHAXPS1\Projects\Administratie Piak\Maand schemas\2011\Paul
I have the same problem, so I tend to suspect a network issue.

So, when I make a copy of an affected file, this copy will work for some time.
Some days or a week or so later, opening the file through double-clicking stops working, all I get is a brief splash screen and then nothing.
Opening the file through a different (network) path still seems to work (does it keep working after some days? will try to find out)
I haven't tried a new file yet, am working on it.

I will try to figure out what triggers the issue
I will also downgrade to openoffice 3.2.1 or 3.2.0 to double check when the issue approximately arose. 

Paul

I just tried out openoffice 3.2.1 and 3.3.0. The issue was not in 3.2.1, but did appear in 3.3.0.

Created attachment 47213 [details]
problematic file (depending on path)

This attached file was created yesterday and worked fine then (I could open calc by double-clicking the document)
After rebooting both computers yesterday it still worked.
Today it doesn't work.
Probably you will find no problems with this file, since I can still open the file through the network path
\\BRAVOXPS2\Administratie Piak\Maand schemas\2011\Paul\Geen titel 1.xls
However when double clicking
\\BRAVOXPS2\Projects\Administratie Piak\Maand schemas\2011\Paul\Geen titel 1.xls
I only get the splash as described in previous comments.

By the way, when trying today, I did get the question whether I wanted to restore a document. After finishing ('no') this dialog, calc did not start further.
This may give some information how far calc got in the startup procedure.

Paul

is there something "special" with the UNC path \\BRAVOXPS2\Projects\Administratie Piak then? Or is just "Projects" a perfectly normal share on the BRAVOXPS2 server, and its subfolder Administratie Piak just happens to be also shared (so that files under it can be accessed using two different UNC paths)?

Could some protection issues be involved? Are these two shares (Projects and Administratie Piak) protected (on the server) in different ways? Or do you access them in different ways, using different authetication, etc? I am no Windows sysyadmin, so I am mostly throwing up terms in the air that sound relevant here;) Please could you ask your Windows sysadmin people to investigate, if possible...

(In reply to comment #14)
> is there something "special" with the UNC path
> \\BRAVOXPS2\Projects\Administratie Piak then? Or is just "Projects" a perfectly
> normal share on the BRAVOXPS2 server, and its subfolder Administratie Piak just
> happens to be also shared (so that files under it can be accessed using two
> different UNC paths)?

The latter.
> 
> Could some protection issues be involved? Are these two shares (Projects and
> Administratie Piak) protected (on the server) in different ways? 

The only difference is that Projects is also visible to 'everyone'
> Or do you
> access them in different ways, using different authetication, etc? 

I am not aware of having supplied different credentials for the two paths.
I would like to reset the login information but have never been able to find the place where windows xp/vista/7 stores that. But that is an other question.

> I am no
> Windows sysyadmin, so I am mostly throwing up terms in the air that sound
> relevant here;) Please could you ask your Windows sysadmin people to
> investigate, if possible...

That would be me then....we're only a 2 person company.

About the authentication issue:
- I can open the file when calc is running file->open-> etc
- A reboot of both systems does not seem to influence the issue, this would require re-authentication I would suspect.
- On a new file the issue appears the next day, note that both computers are running 24/7, no sleep/or hibernation.
- when I make a copy (copy-paste in windows explorer on 
\\BRAVOXPS2\Projects\Administratie Piak\Maand schemas\2011\Paul\Geen titel
1.xls (the problematic path)
the copy file has no issues, although it would have inherited properties from the original. (Or does it inherit properties from the parent folder? Something to find out)

I did one experiment and the trigger to the problem seems to be a nightly synchronization with robocopy. Will investigate what is modified by making a copy of the file on a different location. 
If I find a change it may lead us to the problem in libreoffice.

Paul

An additional peculiarity:
When I delete the file and make a new copy with the same name as the problematic file that was just deleted, the new copy has the same problem. The name of the problematic file is remembered somehow by either windows or libreoffice. It is not the file itself that is problematic.

Paul

Paul, Tor, Fridrich...

I noticed when installing libreoffice 3.3.2 (my first with Libreoffice) on top of OpenOffice.org (GOoo actually 3.2) that the paths in the registry were not updated by the LibreOffice installer. I manually edited all OpenOffice and Sun Office entries in the registry (regedit) to point to the Program Files\LibreOffice 3\  directory, and I was thereafter able to find swriter, scalc etc in "Open with" after a right click. Double clicking on odt files then also started working. My windows version is some build of XP SP3.

After installing Libreoffice 3.4.3  (LibO_3.4.3Win_x86_install_multi.exe) I found that now references to the \LibreOffice 3\ path had not been changed to \LibreOffice 3.4\ which was the new directory in \Program Files\. I copied all the file/directories from \LibreOffice 3.4\ this time to the still extant but almost empty \LibreOffice 3\ directory .. and once again things began to work again, although when starting LibreOffice, some functions seemed to have been disabled. In the directory setup (after starting sOffice) I found only \LibreOffice 3\ directory references.

I thus speculate (reason?) that the cause of this bug (in Windows) may partially lie with the installer not correctly building or updating registry entries if a previous version of Open or LibreOffice exists.

I hope this contributes a potential line of investigation, and is not just a waste of time.

Max

Hello Max, Tor, Fridrich

I don't think it is the same issue since I do get the splash window, so it seems windows knows what program to use. 
It needs a remove-clean-reinstall, which I believe I already did several times.
Will try again when I find some time

PAul

Hello,

As you may have noticed, I have been too busy and this issue was of too little importance to me.

I recently updated to 3.4.4 which seems to have fixed the issue. I think this issue can be closed.
Thanks,

Paul

I think that I have the same issue with LO 3.4.5 final for Debian Linux.
When I open a file with spaces and parentheses and other UTF-8 characters in the name with command line or clinking in Nautilus, the file is not found by Libreoffice.

I also have a double-click startup problem, but can't find out why, what or when (but by opening a document directly). Calc and Writer, xls and ott. Please see https://www.libreoffice.org/bugzilla/show_bug.cgi?id=46407#c1 . I didn't have the problem with 3.5.0, but with 3.5.2 .

Now, this issue seems fixed In 3.5.2 release for Debian OS.

NB : Please do not change the platform target, Linux is also concerned.

Since it's been working for the reporter since 3.4.4, put it WFM.