Created attachment 51422 [details]
File that doesn't work properly with Libo 3.4.3
This spesific file that has grown over time is either corrupted, or there is a bug in LibO.
Step to reproduce:
* Open atached file
* Add a new spreadsheet before "Bensin". Name can be anything.
* Try saving the file. Now, LibO cannot save that file. Any work will be lost.
File system (including use of rare characters) is proven to not be the teason why LibO fail to save after the preceeding steps.
I need to add another spreadsheet into this file to continue some work. Any workarounds?
OT: I'm sorry I wrote a bug repport where I assumed that the file saving error was caused by some file name restrictions.
Tested same file with Open Office 3.3.0 (not an installed version)
Followed same steps to reproduce. Success.
Have now uninstalled LO 3.4.3 and installed LO 3.3.4.
Adding another spreadsheet works fine with LO 334, and A'm able to save correctly.
I reproduce the problem with LibreOffice 3.4.3 under Ubuntu 10.04 x86_64
Set platform and OS to ALL
Best regards. JBF
[This is an automated message.]
This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it
started right out as NEW without ever being explicitly confirmed. The bug is
changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back
to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases.
Details on how to test the 3.5.0 beta1 can be found at:
more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Reproducible in LO 3.5.0 beta2+ (LibreOffice 3.5.0beta2+ Version ID : 8f03437-7f15fca-1fc8c06-ca8e46d-b96fade) but saving the modified file under another name (File > Save As...) works well and the new file can be modified and saved again.
@Grobe: Please, could you try again with current pre-release of LO 3.5.0?
Best regards. JBF
I have now tested some few ODS files from early 2007 (created with that time latest version - not beta - of OO) and tried to insert some atitional sheets with differnet names. On that spesific test I could not reproduce the failure.
Also, the files semms to be in good conditions (ie. not corrupted).
I tested with Libre Office (I just discovered I had tested with the previous version because the installer didn't make ods files open in recent version. Have to make the test over again) - forget the previous comments As I have to do the test over again.
Means that after installing LOdev, any odx files seems to opens in preivious installed (stable) version.
Ok, I have now tested with LOdev 3.5.0beta2
Build ID: 8589e48-760cc4d-f39cf3d-1b2857e-60db978
A insert-sheet test on three different ODS files as mentioned above did not trigger any bug as I could see.
Thank you for these additional tests. So closing as WorksForMe. Feel free to reopen if the problem comes back.
Best regards. JBF
Reopen - the attachment from the first comment
does show the bug in 3.4.5 rc2
(it's great that not all files / new files / all versions have the problem, but this still is a bug - and a severe one)
Created attachment 55410 [details]
ods to reproduce the problem
create attachment that I have to reproduce the problem:
LibreOffice 3.4.5 rc2
- right click on sheet 'leeg'
- choose Move / copy sheet
- choose Insert , before '2010'
> error with saving file ...
problem on writing
file cannot be saved
*** Bug 41085 has been marked as a duplicate of this bug. ***
*** Bug 44528 has been marked as a duplicate of this bug. ***
already a problem in 3.4.0 :-) :-\ :-(
maybe, it is only a corner case that happens only very rarely and it is not that critical; Cor wrote that it was already in 3.4.0 and we got only few reports
@petr: that is why I choose 'Major'
However, this history does shows another problem. Might be major, might be critical
I am unable to reproduce this with 3.5.0-beta3 on Linux-x86_64 => it seems to be fixed in 3.5.
I wonder if is worth to fix this for 3.4.6. I think that we should not block 3.4.5 with this. It is about to get published.
I'll look into this problem.
Might be that the bug is fixed or hidden in master by my sheet container rework.
This is a drawing object relocation issue which is fixed in 3.5. Try Beta3 if it is still reproducible.
The bug gets triggered only when the drawing objects (including cell comments) are located on sheets that get relocated when a new sheet get inserted. E.g. there is a cell comment on sheet 3, insert a new sheet at sheet 2 position, sheet 3 gets shifted to the right. When saving the file, you get an error.
Unless this bug report is specifically for backporting the fix to 3.4 (which at this late stage I feel rather reluctant to support), I'd like to mark this as fixed in 3.5.
show as fixed. seems to be ok at this point.
On Wednesday, 01/11/12 10:03 AM, email@example.com wrote:
> --- Comment #19 from Kohei Yoshida<firstname.lastname@example.org> 2012-01-11 08:03:21 PST ---
> Unless this bug report is specifically for backporting the fix to 3.4 (which at
> this late stage I feel rather reluctant to support), I'd like to mark this as
> fixed in 3.5.
Thanks. I'll mark this as fixed in 3.5.
I guess fixing in 3.4.6 too would be highly practical for (prof.) users and appreciated ..
(sorry that these issues have not surfaced faster, but that does not prove that they are not annoying etc. etc.)
Cor; Kohei wrote:
> Unless this bug report is specifically for backporting the fix to 3.4
> (which at this late stage I feel rather reluctant to support), I'd
> like to mark this as fixed in 3.5.
Which suggests to me that the code changes are potentially substantial, and may cause further work and knock-on regressions in 3.4.x - which is reaching the end of it's life.
As such, this bug prolly is better marked closed in 3.5. Kohei do you have a pointer to a commit you think may have nailed this in 3.5 so we can have a quick 2nd look ?.
(In reply to comment #23)
> As such, this bug prolly is better marked closed in 3.5. Kohei do you have a
> pointer to a commit you think may have nailed this in 3.5 so we can have a
> quick 2nd look ?.
Well, I've fixed a whole bunch of things in calc's drawing layer code, and I don't know which one did fix this one. Digging relevant commit(s) will take a while.
Is there any workaround that 3.4 users could use when they become to this situation?
The description of the bug sounds scary but I see only two duplicates, so it might be a kind of corner-case. I am not sure if it make sense to spend ages on backporting the fix. A workaround might be enough. We might mention it at
(In reply to comment #25)
> Is there any workaround that 3.4 users could use when they become to this
I just tried one possibility. Quite clumsy
- insert copy at first position
- Ctrl-S (save)
- Ctrl-Z (revert)
- instert copy at last position
- Ctrl-S (save)
> OK :-)
Moving the sheet to another position as well as inserting it at the end immediately fail in my situation.
Not too reliable, and of limited use.
Maybe someone else hase more success?
Fixed in 3.5 and 3.4 will not get a new release.