Created attachment 59672 [details] Excel-sheet with malformed external links libreoffice: Installed: 1:3.5.1-1ubuntu1~lucid1 Candidate: 1:3.5.1-1ubuntu1~lucid1 Version table: *** 1:3.5.1-1ubuntu1~lucid1 0 500 http://ppa.launchpad.net/libreoffice/ppa/ubuntu/ lucid/main Packages 100 /var/lib/dpkg/status In LibreOffice Calc 3.5.1-1ubuntu1~lucid1 (PPA) and 3.5.2-1 (Debian unstable) there are problems with malformed links to external Excel-sheets. Make a source.xls and a merged.xls. Type in source.xls [A1]number [A2]A [A3]B [B1]value [B2]11 [B3]22 Type in merged.xls [A1]number [A2]A [A3]B [B1]value [B2]25 [B3]45 Make in merged.xls [C1]diff [C2]=B2-'file:///tmp/source.xls'#$sheet1.B2 [C3]=B3-'file:///tmp/source.xls'#$sheet1.B3 The sheet merged.xls shows now in [C2]14 and [C3]23. If you close merged.xls and reopen it, you get a message "… contains links … should they be updated?" and an error. =B3-'file:///tmp/tmp/source.xls/'#$sheet1.B2 The path-name was saved (or reloaded) wrong into [C2] and [C3]. As LO-users will/must cooperate with MSO-users, they can't use LibreOffice 3.5 because the malformed links to external sheets. To let all switch to ods-sheets is not an option "at the office". There is no work-around atm with other formats like xlsx. I tested in 3.4.4 links to other sheets - works fine there (tested with Oneiric). (I heard also about normal behaviour in Debians LibreOffice calc 1:3.4.6-2.) libreoffice: Installed: 1:3.4.4-0ubuntu1 Candidate: 1:3.4.4-0ubuntu1 Version table: *** 1:3.4.4-0ubuntu1 0 500 http://nl.archive.ubuntu.com/ubuntu/ oneiric/main i386 Packages 100 /var/lib/dpkg/status 1:3.4.3-3ubuntu2 0 500 http://nl.archive.ubuntu.com/ubuntu/ oneiric/main i386 Packages Can we go back to the behaviour of 3.4.x to make/save/reload links to external sheets?
Deleted "regression" from Headline and used the keyword instead
Please don't mark bugs as blockers. A blocker bug is reserved for really serious bugs that affect all users and not a normal bug in a non native export filter. Even in ods export/import this would not count as a blocker bug.
Today I tested those files with LO 3.5.1 on Windows (XP SP3). No problem at all. Maybe it's a only a posix-problem. But if "anybody" see the importance of this issue for all clients "at the office" in multi-platform environments now, please fix it quickly.
It's the same problem in libreoffice: Installed: 1:3.5.2-3 Candidate: 1:3.5.2-3 Version table: *** 1:3.5.2-3 0 500 http://ftp.nl.debian.org/debian/ unstable/main amd64 Packages 100 /var/lib/dpkg/status
(In reply to comment #2) > Please don't mark bugs as blockers. > > A blocker bug is reserved for really serious bugs that affect all users and not > a normal bug in a non native export filter. Even in ods export/import this > would not count as a blocker bug. My blocker-label was a little stammtischly, I agree. In a FOSS-friendly environment we all can accept oops-situations. And we have "enough time" in those environments. At the office - we have not. Every developer should think about the thousands of Linux+LO-users at very FOSS-unfriendly offices. Those users work in the frontline every day to declare LO is good and sometimes better than MSO. Everytime if I have a chance to let see MSO-users advantages of the LO-packages I will do that. The malformed external links in xls-sheets are a very serious problem for "normal" Linux+LO-users. Most of them have not enough time to report/confirm/test etc. about packages. Maybe they are not an enormous league of users, but just they daily propagate FOSS. I hope 3.5.3 will bring me and other "early adopters of a new Final" the solution for the xls-links and even for some layout-issues. btw. Yes, my Denglish is grottenschlechtly - I know that, but I report no lyrics.
[Not Reproducible] with LibreOffice 3.5.2.2 - Win XP (32bit) Spanish UI [Reproducible] with LibreOffice 3.5.2.2 - Debian 6.0.3 squeeze (32bit) Catalan UI. The path returns duplicated when you save and reopen the document, and gives you an error. You must edit and manually modify the path to perform the refresh.
... issue is not solved in Ubuntu 12.04 with LO 3.5.2-2ubuntu1 Debian sid with LO 3.5.2-6 Ubuntu 10.04.4 with LO 3.5.3-0ubuntu1~lucid1 (ppa)
issue also "available" in libreoffice: Installed: 1:3.5.3-3 Candidate: 1:3.5.3-3 Version table: *** 1:3.5.3-3 0 500 http://ftp.de.debian.org/debian/ unstable/main amd64 Packages 100 /var/lib/dpkg/status> libreoffice: and libreoffice: Installed: 1:3.5.3-0ubuntu1~lucid1 Candidate: 1:3.5.3-0ubuntu1~lucid1 Version table: *** 1:3.5.3-0ubuntu1~lucid1 0 500 http://ppa.launchpad.net/libreoffice/ppa/ubuntu/ lucid/main Packages 100 /var/lib/dpkg/status
<http://wiki.documentfoundation.org/BugReport_Details#Version> I (more or less) can confirm Vicent Vendrell's results: NOT reproducible with "LibreOffice 3.5.4.1 (RC1) German UI/Locale [Build-ID: 7306755-f4f605c-738527d-1cf4bc1-9930dc8] on German WIN7 Home Premium (64bit) [Reproducible] with "LibreOffice 3.5.3.2 German UI/Locale on German Ubuntu 12 (64 Bit) Because "merged.xls" from test kit immediately shows an update error when opening it I created a new test document "merged_new.ods" what contains 2 Formulas: In C2: = (This document B2) - (B2 insource.xls) In C3: analogous Steps to reproduce with reporter's test kit and "merged_new.ods" 1. download "merged_new.ods" and copy to folder containing reporter's unzipped test kit 2. Open "merged_new.ods" under Ubuntu > opens without error message and show correct Results in C2,C3 3. Save "merged_new.ods" as "merged_new.xls" (Excel 2003) 4. close "merged_new.xls" 5. reopen "merged_new.xls" Expected: no problems as in step 2 Actual: damaged link to "source.xls" as reported Currently a FILEOPEN problem is not 100% excluded @Markus: you already have been involved; please set Status to ASSIGNED and add yourself to "Assigned To" if you accept this Bug
Created attachment 61901 [details] Nes sample document See Comment 9 how to use
Thank you both, Rainer & Vicent. I tried today not 10.04 Lucid with a ppa, even not a Debian sid system, but again with Ubuntu 12.04 - a mainstream Linux distribution launched with LTS and without any ppa or “unsupported" modifications. I followed your steps and I can confirm your results are reproducible with an upgraded Ubuntu 12.04 32bits-system: Distributor ID: Ubuntu Description: Ubuntu 12.04 LTS Release: 12.04 Codename: precise English UI/Locale on English Ubuntu 12.04 Architecture: i386 Source: libreoffice Version: 1:3.5.3-0ubuntu1
Bug is not solved in (Xubuntu 10.04, 64bits) Installed: 1:3.5.4-0ubuntu1~lucid1 Candidate: 1:3.5.4-0ubuntu1~lucid1 Version table: *** 1:3.5.4-0ubuntu1~lucid1 0 500 http://ppa.launchpad.net/libreoffice/ppa/ubuntu/ lucid/main Packages 100 /var/lib/dpkg/status (also "available" for Debian sid 3.5.4-3) Test-procedure: 1. open the "old" merged.xls shows damaged links 2. repair path in link with LibO 3.5.4.2 (shown in LibO-info = 3.5.4-0ubuntu1~lucid1) 3. re-open file Result: the damaged external link is back again
Don't change the version number! And as long as it is not commented in the bug report that the bug is fixed we did not work on it. Commenting for each release only produces noise and does not increase my motivation to fix this.
Maybe a longer explanation could help ... ... it's not my intention to let this issue grow to become a "personal thing" between you and me. So - p(l)ea(s)ce: It's my intention to make LibO / Firefox / whatever FOSS better. The malformed links issue was founded by another user, but he don't reported this on Freedesktop. I did precisely that what you asked for on 2011/06/19: >>What is your vision for the future and/or what would you most like to see improved ? >It would be amazing if more people would help in the QA and help the developers to find bugs much earlier. As usual there never was/is much time for a decision at the office. background: I'm part of a work-group/panel to advice the management of a new public affairs organisation about decisions for a lot of applications (platform independent, cloud, formats, office software etc.) for 100+ clients. In this work-group I'm a little player with a very little chance to promote/advice LibO or other FOSS-applications. My knowledge to integrate "all applications" to a new desktop for all kind of users (Windows/OSX/Linux) is not one as a level of IT-developper / architecture consultant. Sometimes I can only tell the other members about some issues: like "this software we need" and "those won't work" ... because there are some known bug-issues or support-issues imho. That's why I'm a little hasty with the issue. back to LibO calc: My point of view is a user-view and I see other bug-fixes in 3.5.x but I hadn't heard about a decision or time-path to fix the malformed XLS-links or something like "a fix not before" information. Because my user-view I changed the version number, maybe any user will search/filter results with a release number of LibO. Some other users informed me about a new LibO-version and from them I heard "maybe it's fixed now". The user-view about software-issues was/is/will be never the same view as the developer- or helpdesk-view at the same issue, not in terms of importance and also not in terms of communication. I'd changed the version number earlier (2012-04-13) and heard nothing like "don't do this, because this isn't usual" and "produce noise" in LibO-development. If any developer told me "it will take a month or two", it was ok for me. But I heard not so much about the malformed links issue. If users could have some information about the possibility for a fix (like: to fix in version 3.6.* ...), somebody can decide to stay & wait, downgrade to LibO 3.4.6 or test & migrate to Apache OpenOffice 3.4. Maybe it was my own wrong decision at all to start with LibO "at the office". Microsoft Office is also available and can be installed in various versions on a Linux desktop (if Outlook or Access are not necessary). I understand your point "we need more test-results from users / early adopters". And if they respond, maybe they will not respond like you think they should. Only a very small group of users will report bugs at all and within this group much of them "report" bugs in a forum which is not related to TDF. And only some of them will report on bugs.freedesktop.org. I think the chance of a bug-report in a developer-format & tech-language that also fits to the chosen bug-report-platform isn't so big.
Here are my results from bibisecting (3.5 on Ubuntu 11.10), following Bielefeld's repro steps. Couple of notes: 1) Opening the ODS file would immediately pop-up a dialog asking if I wanted to update the remote sheet values. I said yes. 2) I considered a failure to be a run in which I saw the duplicated-path error dialog. ---------- 0c87fc8ce8c0a967e4527fe426ed76156f6f5377 is the first bad commit commit 0c87fc8ce8c0a967e4527fe426ed76156f6f5377 Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Wed Dec 7 20:49:48 2011 +0100 source-hash-fd4c879e2ebd5920b48b2e48ac32181565f5ee1b commit fd4c879e2ebd5920b48b2e48ac32181565f5ee1b Author: Tor Lillqvist <tlillqvist@suse.com> AuthorDate: Tue Oct 4 23:56:02 2011 +0300 Commit: Tor Lillqvist <tlillqvist@suse.com> CommitDate: Wed Oct 5 09:34:16 2011 +0300 s/dump/print :100644 100644 856232905027927b3e83a9750f97f8f81013a811 b3fd432cc0df22ec329e330d2c9fbdae276b7ffc M autogen.log :100644 100644 4256cf1f3fff2210d09f32c15dbd4b8dea7233cc 70e55cd0741e6174fa19372205215a00b40d542c M ccache.log :100644 100644 bb37f03cc94509b1123010d65897c06c21b4ca3a 6c463672cca0b2c8f05a6335c1dfd80a00f33172 M commitmsg :100644 100644 14f89dac8e86702306e3bd0d34749658c7f8dac3 509554216f2d576ed4ffd9adad67380a2ebcda80 M dev-install.log :100644 100644 6c3c85d78110956942a99658c13194d7fbaf20f1 cfe0830fa908dfd9f12a7c8845a0676c465e3273 M make.log :040000 040000 73b2e091f7d74501543c61315de98cae22011af8 dead807550c17b2cbe408a476ca5ede42c1752ab M opt $ git bisect log # bad: [4c30602f43475389f81b1d981ce8ee9a3410b9d9] source-hash-85c6244b85b29c1d2bb9d89b62e9512dd65378b5 # good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932 git bisect start 'latest' 'oldest' # bad: [2faf4bc12ab490370d2196dedbc8091f9b09d0a5] source-hash-418a35f4861e863feb39eec73f4a39a87fbcb1f3 git bisect bad 2faf4bc12ab490370d2196dedbc8091f9b09d0a5 # bad: [2faf4bc12ab490370d2196dedbc8091f9b09d0a5] source-hash-418a35f4861e863feb39eec73f4a39a87fbcb1f3 git bisect bad 2faf4bc12ab490370d2196dedbc8091f9b09d0a5 # good: [4bae211a2589ecaec48c1409cf7cd1580d3e14c5] source-hash-31e7820f03badc3c6fe8fdaffb74f2125e05ea96 git bisect good 4bae211a2589ecaec48c1409cf7cd1580d3e14c5 # bad: [eca91b9203dad6a608086451c6ad119f856782e4] source-hash-003973f5d461b981737946456eb08b2b7d60f150 git bisect bad eca91b9203dad6a608086451c6ad119f856782e4 # bad: [aa8184788de7b0f5b8f11d898d4ef3178a5573b6] source-hash-e5f71ca7c27259360a401d94ed6a53038608b941 git bisect bad aa8184788de7b0f5b8f11d898d4ef3178a5573b6 # bad: [0c87fc8ce8c0a967e4527fe426ed76156f6f5377] source-hash-fd4c879e2ebd5920b48b2e48ac32181565f5ee1b git bisect bad 0c87fc8ce8c0a967e4527fe426ed76156f6f5377 # good: [4e15e542a52c633ba8051d51efb0637d0d71d493] source-hash-350e1e245643e107b6e46b2de3dc73906ab844a5 git bisect good 4e15e542a52c633ba8051d51efb0637d0d71d493
> ---------- > > 0c87fc8ce8c0a967e4527fe426ed76156f6f5377 is the first bad commit > commit 0c87fc8ce8c0a967e4527fe426ed76156f6f5377 > Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> > Date: Wed Dec 7 20:49:48 2011 +0100 > > source-hash-fd4c879e2ebd5920b48b2e48ac32181565f5ee1b > > commit fd4c879e2ebd5920b48b2e48ac32181565f5ee1b > Author: Tor Lillqvist <tlillqvist@suse.com> > AuthorDate: Tue Oct 4 23:56:02 2011 +0300 > Commit: Tor Lillqvist <tlillqvist@suse.com> > CommitDate: Wed Oct 5 09:34:16 2011 +0300 > > s/dump/print > Thanks a lot for this bisecting. it helped to find a possible candidate. @Kohei: Can you have a look at this one? It seems that 0e1de41755fd3e9f9e1c42edb7285e64aff07218 is the most likely resopn for this bug.
It's a known issue that you can't save correct external path when saving from non-Windows platform (because we don't know which drive (i.e. C:, D: etc) the file is located). If you need to interact with real Excel users wrt external references in xls format, then you need to save those files on Windows. This is not a bug, but a known limitation and there is no fix for it. The previous scheme may have "worked" in some circumstances but it was not done according to the MS documentation and in some cases it would save the external paths incorrectly (even on Windows).
Taking out the regression keyword. Technically this is a platform-dependent limitation, not a regression. The old scheme didn't work when source and destination files had different drive letters.
Thanks Kohei, I struggled for months with this on OSX before finding this bug report. For clarity: Is there an alternative format that can be used to share spreadsheets with MS Excel users, that does not suffer from this problem?
They can probably just specify a new file locations via Edit Links dialog, can they?
There appear to be two separate issues here: 1) prepending the path every time the sheet is opened on a non-Windows platform. It would be good to suppress this behaviour, perhaps by checking uname or by building differently for Windows. 2) getting the drive letter included when the sheet is opened on a Windows platform. I'm sorry not to have a good suggestion, but I don't see how prepending the path helps (unless it just suppresses a syntax error in Excel). Would a relative path help? (I'll go quiet now as I don't like to stir things up without having a positive contribution to make)
>Would a relative path help? That's good enough for me. If LibO see a strange path in an xls-sheet to an external sheet, there should be a pop-up like "malformed links to external Excel-sheet", this is a known limitation please read instructions on freedesktop-blabla or LibO-help-issue-1234. ... and in the helpinfo: this only works "platform-independent & correctly" if source and destination file(s) are placed in the same directory AND if any link tot an external sheet was made under this condition. Otherwise you must edit the link in/to the sheet by hand two times: if you work with those files on Linux/OSX+LibO and edit again if you open the file on another workstation (or VM) with Windows+MSExcel.
All links should be updated automatically when you choose a new file via Links dialog.
Problem still exists in 4.0.0.3 (OSX)
*** Bug 64180 has been marked as a duplicate of this bug. ***
Problem still exists in 4.0.2.2 Arch Linux build-3
*** Bug 56650 has been marked as a duplicate of this bug. ***
*** Bug 67806 has been marked as a duplicate of this bug. ***
Hi Kohei, (In reply to comment #17) > It's a known issue that you can't save correct external path when saving > from non-Windows platform (because we don't know which drive (i.e. C:, D: > etc) the file is located). If you need to interact with real Excel users > wrt external references in xls format, then you need to save those files on > Windows. Do you mean that it is just a limitation of working on a non-windows os? Thus when the original reporter, who created two xls-files on Linux, would have done the same with two .ods-files, would have had the same problem?
re-reading the reports, I think it is not correct to have the OS in the summary. Removing that now (I added it previously myself...) reading comments in duplicates https://bugs.freedesktop.org/show_bug.cgi?id=67806#c0 https://bugs.freedesktop.org/show_bug.cgi?id=56650#c0 they say that the path to the file is always doubled. Useful information?
@kohei, Sorry for adding you in cc here. Just wrote comment 29 with a question to get more clarity. Thanks, Cor
(In reply to comment #29) > Hi Kohei, > > (In reply to comment #17) > > It's a known issue that you can't save correct external path when saving > > from non-Windows platform (because we don't know which drive (i.e. C:, D: > > etc) the file is located). If you need to interact with real Excel users > > wrt external references in xls format, then you need to save those files on > > Windows. > > Do you mean that it is just a limitation of working on a non-windows os? > Thus when the original reporter, who created two xls-files on Linux, would > have done the same with two .ods-files, would have had the same problem? No. If you saved as ods you won't have this problem. Only when you save it as xls you would have this problem. I've already explained this in detail, so I won't repeat myself here. Removing myself from CC again.
@Kohei Thanks, adding you once more for requesting additional info. (In reply to comment #32) > No. If you saved as ods you won't have this problem. Only when you save it > as xls you would have this problem. > > I've already explained this in detail, so I won't repeat myself here. Your initial comment caused some confusion, sorry, because you made a relation to the OS. However this issue is indeed about the use of xls versus the use of ods. And indeed it is a regression. Can you pls advise on whom to ask for the xls-filter? > Removing myself from CC again. I'm willing to do that again for you of course when things are clear. But feel free to do that again ;) Cor
Cor: Kohei wrote: > I've already explained this in detail, so I won't repeat myself here. Please don't CC him on the issue again - it is 100% clear that he doesn't want to be CC'd here - and I'd prefer not to harass our calc engineers. As of now, he's ignoring all CC's on bugs because of this - I'd like to change that. This bug is awaiting a patch from someone (not a core calc guy) to add whatever consolidated warning feature they want to - though that should really be another bug I guess. Failing that - I'd expect a really detailed rebuttal of what Kohei wrote - with a concrete proposal for what to do in the corner-cases, citing what the relevant specs said, giving concrete examples of use-cases and the impact of this regression etc. All presented in a format that is comprehensible to developers and shows the hard work has been put in to plot a credible new path here - ie. making it easy for them. Thanks.
Hi Michael, I know that regularly miss things, or make mistakes (not that I think that I'm particularly stupid, but mostly because the number of (different) topics that I give attention to, is basically a little too much. Which is stupid of course..) Therefore, when some days ago someone filed a bug that happened to be a duplicate of this one and that I spent some time on.... I carefully looked at the history of this bug, and found that it was me (I didn't remember this) who some time ago, beacuse of how I understood comment 17 , added 'Windows OS' to the summary and at the same time removed the keyword 'regression'. That made me look at the various comments again, also of the duplicate bugs, which gave me the impression that the changes I made before to the summary/keyword, could_ be wrong. So I did some additional tests, and indeed could confirm the described behaviour: - external link to a file on a non Windows platform (Linux) works fine in ODS but not in XLS. - that this wasn't a problem in 3.4.x – the first 3.5-build that I have available, (3.5.0-beta1.a) does have the problem. Now I was confused by how to understand comment 17 , so to take it serious, I had asked some extra information. As I understood it, that confirmed that Windows OS is not relevant in this issue. That it was mentioned in the other comment was confusing or maybe related to another topic. I don't know. Anyway, in this issue it is the file type that is relevant. Thus all I wanted to know is which person is the best to look at the filter. Of course I apologise if I was wrong. And obviously had no intention to be rude nor impolite to anyone. If my question turned out to have that effect. I seriously apologise. Kind regards, Cor
*** Bug 70304 has been marked as a duplicate of this bug. ***
Because Kohei has clearly explained the issue here I am closing this as NOTABUG - it is a known limitation that he has explained clearly enough for everyone to understand.
*** Bug 75169 has been marked as a duplicate of this bug. ***
*** Bug 70970 has been marked as a duplicate of this bug. ***
*** Bug 77737 has been marked as a duplicate of this bug. ***
*** Bug 79630 has been marked as a duplicate of this bug. ***
*** Bug 80641 has been marked as a duplicate of this bug. ***
*** Bug 89233 has been marked as a duplicate of this bug. ***