Apache OpenOffice (AOO) Bugzilla – Issue 85650
Problems with opening .xls files on shared folders in XP on Parallels on Mac
Last modified: 2013-02-11 06:12:28 UTC
I'm having some difficulties opening files in my current configuration. I suspect this bug is new, as no other bug had "Parallels" in the title. I'm not sure if I've entered the correct fields for this bug report; I'm not sure which component is involved with opening files. I'm also not sure if this problem relates to OOo, to Parallels, both, or neither (I could find no similar bug here or on forums.parallels.com). I'm reporting it here first, as I suspect the problem is with an OOo component. If it is not an OOo problem, I hope this report is sufficiently detailed that I can post an inquiry on the Parallels support forums with a link to this bug report. SYSTEM CONFIGURATION: I am running OSX 10.4.11 on a 2.16 GHz Intel Core 2 Duo mac. I have Parallels 3.0 (Buld 5582), running Windows XP SP2. I have OOo 2.3.1 installed on the virtualized XP. I have my OSX User/Public folder set as one of my Parallels Shared Folders, so that files in that folder are accessible from within XP (as "[Username] Public on .psf"). I do not have MSO installed on XP; however, I do have MSO 2004 installed on OSX. Within XP, MSO files are set to open with OOo by default (though "Microsoft Excel (Mac)" is an option in the "Open With" context menu option) To maximize reproducibility, the spreadsheet documents mentioned below were created as follows: - Open OOCalc - Type "test" into cell A1 - Save as "psf doc test.xls" and again as "psf doc test.ods" onto XP desktop - Copy/paste into "[Username] Public on .psf" folder DESCRIPTION OF PROBLEM: Within XP, I navigate in Windows Explorer to the folder "[username] Public on .psf", usually by clicking on my "Parallels Shared Folders" icon on the desktop, then clicking on the "[username] Public" network folder icon. When I double-click on a file icon in that folder (or right-click and ask it to open with OOo), I get a variety of inconsistent, strange behaviours. (Double-clicking on files that are on the XP desktop or elsewhere within the XP filesystem works fine) Unfortunately, I don't think I can compile an exhaustive list of trials, but here is a selection: - Note: the QuickStarter is not yet open (and soffice.bin/exe processes are not running in the Task Manager) - Clicking on an .odg file starts the quickstarter and opens a new OODraw document. In a second attempt, it started the soffice.bin and .exe processes but the Quickstarter did not appear, nor did the new document window (ERROR: should open the .odg file) - Clicking again on the same file (whether the previous window was left open or was closed) does nothing. Once or twice it initiated a second soffice.(bin?) instance, which immediately terminated, but a second Quickstarter icon would appear, and one of the two would disappear as I hovered over it. - With the quickstarter running (i.e. by opening OOo from the Start menu), I can right-click the quickstarter, click "Open Document", navigate to this .odg file in the "[username] Public on .psf" folder, and it will open the file correctly - Clicking on a .xls file or a .ods file yields similar results. The Quickstarter didn't open, but that could be for the same reason that it only opened the first time I tried the .odg file (as I haven't restarted XP since trying that one) - Opening the .xls file and .ods file from the QuickStarter appears to work alright. - One of the .xls files I was trying earlier actually opened in Writer/Web when I tried opening it in the quickstarter, however that was a .xls file created by a custom app from one of my company's suppliers, and that file was opening strangely in MSO 2004/OSX as well (though it seemed to open alright in OOo when I open it from the desktop...). - This last one is the main reason I wanted to make the bug report, but I suspect now that the opening-with-writer/web problem is a problem with our vendor trying to create a .xls file, more than a problem with OOo. Nevertheless, there is still a problem with opening the real OOo files. TEST CONTROLS: - As a control, other file types open properly in XP when I double-click them from the "username] Public on .psf" folder in XP. For example, a PDF file opens properly with Adobe Reader, and a .txt file opens with Notepad (although it will not open with OOo if I right-click and tell it to do so). - I also created another file, using MS Excel 2002 SP3, on another machine ("the Dell") that shares the Windows network with my XP machine on Parallels. I saved this file into the Dell's Shared Documents folder. Accessing this folder from my OSX/Parallels/XP/Windows Explorer, I was able to double-click the file, and it opened normally with OOo. I appreciate the community's assistance in this, and I hope my time spent creating this bug report will not be in vain!
Resolving as invalid, not our bug. Solid and complete issue report. But problem was a know usability issue with Parallels at the v3.0 release. OP can contest, but would recommend open new Issue report, and that only if problem remains when working with a current build of Parallels and AOO.
(In reply to comment #1) > Resolving as invalid, not our bug. > > Solid and complete issue report. > > But problem was a know usability issue with Parallels at the v3.0 release. > OP can contest, but would recommend open new Issue report, and that only if > problem remains when working with a current build of Parallels and AOO. Because opening .xls files worked from the Virtual Windows XP SP2 (why not SP3 for heaven's sake) desktop, but there are problems launching from the shared folder in Parallels, this might be related to file-name handling. The two cases to check are when the file-name is provided to the launching application and when the launched application attempts to open the file. I suspect that quickstarter has nothing to do with it, and it should be disabled to reduce variability. I also suggest simplifying the filenames. No spaces, no brackets if possible. Keeping them in a single case (e.g., all lower case) is also helpful. Another thing to check is to see what Virtual Windows XP SP2 considers the filename to be. This can be determined by navigating to a shared folder, selecting one of the ODF files, and sending a shortcut to the XP SP2 desktop. See if the shortcut launches the application correctly. Also, open the shortcut properties to see what the path is. Try pasting that into the Run ... dialog of the XP SP2 start menu and see if that will launch the application from what XP SP2 treats as the full-path filename of the document. There are other things to do, with the idea of reducing the number of variables and catching the discrepancy in the act. This could be simply a deficiency in the interoperability between the Parallels virtualization and the host file system sharing to the guest system. But AOO might have a hand in it. In other virtual arrangements I have seen applications launch from the share only to fail because their attempt to access the file as named to the application fails. This happens when running installers, for example. The workaround is to copy the document to the desktop first. It would be good to confirm that AOO is not a contributor to the problem, just the same.
@orcmid, Issue is Closed Invalid. Normally would agree to additional dialog, but please note the original date of the issue. Five years old with no activity and current Parallels release is v.8--definitely OBE. Also, have a fair amount of personal experience with earlier Parallels--continuous improvements in interoperability with Guest VMs at each release. But as I noted, OP is welcome to contest if on working with current releases of AOO and Parallels, and yes a host VM with at least Windows XP SP3. Stuart
As OP, I have moved on and am no longer using XP on Parallels. No contest. - RG>