Issue 127624

Summary: Partially Cut&Pasting a line from a file to another corrupt an unrelated line
Product: Calc Reporter: fphenix
Component: editingAssignee: AOO issues mailing list <issues>
Status: CLOSED DUPLICATE QA Contact: Keith N. McKenna <knmc>
Severity: Major    
Priority: P2 CC: damjan, knmc, mseidel
Version: 4.1.4Keywords: data_loss
Target Milestone: ---   
Hardware: PC   
OS: Windows 10   
Issue Type: DEFECT Latest Confirmation in: 4.1.13
Developer Difficulty: ---
Attachments:
Description Flags
first file to cut from to reproduce the issue
none
second file to reproduce the issue ; paste in none

Description fphenix 2017-12-06 12:53:04 UTC
Hello,

I can systematically reproduce the following issue when cut&pasting info from one Calc ods file to another.

The files have lines composed of a few text fields then some formulae fields.

For instance the S38 has "=IF($D38<>"";$E$1;0)"; with a fixed value of 14 in E1.
If D38 is empty then S38 displays 0, if a name is entered in D38, S38 displays 14.

However, If I copy the fields B38 to M38 from one file to the other, but paste these in - say - B55 to M55, then in the receiving file the S55 field is updated BUT the S38 fields also has its formulae modified and pointing on D55, hence displaying incorrect info.

Note: the first file was converted from xls to ods a while ago.

Let me know if you need the files (I won't be able to give them as is, but can try to change de data so it can be send out.

i tried in both 4.1.3 and 4.1.4 with same issue in both.

Thanks,
Comment 1 fphenix 2017-12-06 16:50:21 UTC
Created attachment 86291 [details]
first file to cut from to reproduce the issue
Comment 2 fphenix 2017-12-06 16:51:57 UTC
Created attachment 86292 [details]
second file to reproduce the issue ; paste in
Comment 3 fphenix 2017-12-06 16:52:29 UTC
Addendum

I simplified my files and can attach them.

Procedure to reproduce the issue:

Open OOCalc_bug_127624_2018.ods
Look at S19, the formulae refers to D19, that's fine.
Open OOCalc_bug_127624_2017.ods
Select C19 to Q19 from **_2017
Copy and Cut the selection (I use CTRL-X)
Paste it in/from C15 in **_2018 (I use CTRL-V)
Look at S19 in **_2018, the formulae now refers incorrectly to D15.
(S15 still and also refers to D15 which is fine.)

(likewise with the U column by the way)

Note: I haven't tried fully with a simple Copy (rather than Cut). The issue could be while Cutting then Pasting.
Comment 4 Keith N. McKenna 2017-12-07 05:14:35 UTC
Following the the op's supplied steps I can confirm that cutting from one file and pasting to the other does indeed change the formula at S19 as he states. I used both ctrlx and edit/cut also paste/special. How ever if I use either ctlc or edit/copy to extract the information and then paste it into the second file the formula in S19 remains unchanged.

Tests were carried out on both Windows 10 and Windows 7 with the same results. System and AOO configurations as follow:

For Desk Top Configuration
Intel (R) Pentium(R) CPU 4405U @2.10GHz, 2112MHz, 2(Core(s) 4 Logical Processors
Total Physical Memory 8.00 GB
Operating System: Windows 10 Home Version	10.0.16299 Build 16299
Apache Open Office:
AOO414m5(Build:9788)  -  Rev. 1811857
2017-10-11 20:12
Language: en_US
Additional Language Packs: None

For Tablet Configuration
System Configuration:
Processor: Intel Core i5 CPU M560 @2.67GHz
Installed Memory: 2.00 GB (1.6 usable)
Operating System: Windows 7 Home Premium SP1 64 bit

Apache Open Office:
AOO414m5(Build:9788)  -  Rev. 1811857
2017-10-11 20:12
Language: en_US
Additional Language Packs: None

As there is an apparent work-around, copy rather than cut, I have lowered the severity to Normal
Comment 5 fphenix 2018-11-19 16:03:03 UTC
Hi There,

I've tried it in 4.1.6 and still have the issue.

This issue has been put to Normal/lowest priority last year which I don't quite agree as it does corrupt data if you are unaware of the issue or its workaround.

I do rely on a "Cut&Paste" (instead of "copy&paste + delete") as part of my workflow, so this year I fell in the trap again, and thankfully remembered my issue from last year.
Last year it took me a couple of months before I noticed my final result wasn't correct. Some user may not be careful enough to double check the result.

Any chance to have a look at this data corrupting bug? Thanks.
Comment 6 Keith N. McKenna 2018-12-03 16:30:57 UTC
As there is a data loss/corruption associated with this issue I am raising the severity level and adding the data_loss keyword
Comment 7 fphenix 2019-10-02 12:24:27 UTC
Issue tested in 4.1.7 (see protocol above to reproduce the defect) : still present in 4.1.7.
Comment 8 Keith N. McKenna 2019-10-02 21:20:38 UTC
Even though there is a work around i am raising the priority as this does cause data loss or corruption.
Comment 9 fphenix 2021-12-10 14:44:28 UTC
This cell/formulae corrupting issue is still there in version 4.1.11 (tried with updated software today (10th of dec. 2021) : 
Version 4.1.11 : AOO4111m1(Build:9808) - Rev. bdb20b2a64 2021-09-20 16:18

See my "Comment 3" with the procedure to reproduce using the 2 uploaded files.

Cheers.
Comment 10 damjan 2023-01-14 16:49:03 UTC
This still happens on Windows with 4.1.13, but the latest Git works perfectly on FreeBSD: after cut of C19:Q19 from 2017 and paste to C15 in 2018, the S19 formula in 2018 still refers to D19.

Why?
1. A Windows-specific bug?
2. Some bug in the 4.1.x branch that we fixed in trunk but didn't backport?

Can someone please test with 4.2.x or trunk on Windows, so we can distinguish between those possibilities?

Silent data loss bugs are the worst, and our users deserve better.
Comment 11 damjan 2023-01-14 16:59:06 UTC
I think it was case (2), and it was probably this commit that fixed it. This is a duplicate of bug 118023 then, and we should release this fix to users ASAP!!


commit faa11fa3567bc0a69178888650acd0c4c28386a8
Author: Damjan Jovanovic
Date:   Wed Feb 17 00:03:50 2016 +0000

#i118023# Calc: Cut-and-paste between spreadsheets causes incorrect cell reference changes

When pasting cut cells, Calc updates references to their old positions
to instead refer to their new positions. This is done using the tab index,
row and column, however the document is not taken into account. As a result,
when cutting and pasting between documents, cells in the target document
end up getting changed instead of in the source, potentially leading to
formula corruption, which is undoable but could easily go unnoticed,
causing data loss when the document is saved.

We don't really support inter-document reference updates anyway, so fix
this bug by restricting reference updates to the intra-document cut and
paste case only.

Patch by: me
Reviewed by: kschenk
Comment 12 Matthias Seidel 2023-01-14 17:16:00 UTC
Cherry-picked now for AOO41X.

Can we close this one as duplicate?
Comment 13 damjan 2023-01-14 17:20:57 UTC
It would be best if someone tested first.
Comment 14 Matthias Seidel 2023-01-14 17:23:12 UTC
I can provide a test build in the next days...
Comment 16 damjan 2023-01-17 04:07:37 UTC
I can confirm that the bug is absent from both the latest Git on Windows and Matthias's 4.1.14 build, and can be reproduced by reverting faa11fa3567bc0a69178888650acd0c4c28386a8.

Therefore resolving this bug as a duplicate of bug 118023.

fphenix: thank you for your bug report and sample documents :-). If you like, until the fix appears in a new release, you can use Matthias's unofficial 4.1.14 build, or one of our nightly builds (once we get them working again).

*** This issue has been marked as a duplicate of issue 118023 ***
Comment 17 Matthias Seidel 2023-01-17 09:32:54 UTC
Great!

BTW: I do unofficial test builds for Windows on a regular base:

https://home.apache.org/~mseidel/AOO-builds/

For those who want to test. The next build will include this fix.