Bug 162866 - LO 24.2.1 "acor_fr-FR.dat" not read by LO 24.2.5 and later versions
Summary: LO 24.2.1 "acor_fr-FR.dat" not read by LO 24.2.5 and later versions
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: filters and storage (show other bugs)
Version:
(earliest affected)
24.2.5.2 release
Hardware: All All
: medium normal
Assignee: Michael Stahl (allotropia)
URL:
Whiteboard: target:25.2.0 target:24.8.2 target:24...
Keywords: bibisected, bisected, regression
Depends on:
Blocks: AutoCorrect-Complete
  Show dependency treegraph
 
Reported: 2024-09-08 15:49 UTC by Constant
Modified: 2024-09-19 07:21 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
AutoCorrection French file edited (5.87 MB, application/zip)
2024-09-10 16:27 UTC, Constant
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Constant 2024-09-08 15:49:08 UTC
Description:
Since 2020, I have been constantly adding autocorrections via "Tools>AutoCorrect>AutoCorrect Options" to ensure that each of my errors is directly corrected. My file "acor_fr-FR.dat" is now, to give you an idea, 6,000 KB.

To ensure that this file is shared with my other devices, I inserted it into a Cloud folder (OneDrive) and changed – in "Tools>Options>LibreOffice>Paths>AutoCorrect" – the path to the file so that all my devices can access it and update it.

This lasted from 2020 to 2024. However, since downloading LO version 24.2.5 (and later versions), LibreOffice no longer makes the link with the edited "acor_fr-FR.dat" file of 6,000 KB. The list of autocorrections displayed in "Tools>AutoCorrect>AutoCorrect Options" is now empty.

When I delete the 6,000 KB file, the list comes back, but it is the vanilla list, the basic one that is only 20 KB.

I then put the initial access path back – thinking that it could come from my cloud – and replaced the basic file with my 6,000 KB file. Empty list, again.

When I reset my user profile and replace the file by the 6,000 KB one, same result.

So I uninstalled LO 24.2.5 and reinstalled LO 24.2.1, with success: LibreOffice reads my 6,000 KB "acor_fr-FR.dat" file without any problem. The list is full of my autocorrections since 2020.

However, I am condemned to stay on LO 24.2.1...

There is on Ask a French explanation of the problem before I understood it was linked to the update: https://ask.libreoffice.org/t/desynchronisation-entre-fichier-dat-et-autocorrection/110446

Is it due to a "code" changing into the data files of LibreOffice with LO 24.2.5 and later versions ? Maybe...

Steps to Reproduce:
1. Extract the file "acor_fr-FR.dat" from the LibreOffice 24.2.1 or precedent version (important)
2. Replace the file "acor_fr-FR.dat" of LibreOffice 24.2.5 or later version by the extracted file "acor_fr-FR.dat" from the LibreOffice 24.2.1
3. Open Tools>AutoCorrect>AutoCorrect options

Actual Results:
The list of autocorrections is empty.

Expected Results:
The list of autocorrections full with all the added autocorrections created via LibreOffice before the version LO 24.2.5.


Reproducible: Always


User Profile Reset: Yes

Additional Info:
It is maybe not a bug but just a "code" change. 

However, I would love to know how to adapt my file for the later versions of LO. Because autocorrections is a thing! I can’t write without anymore.
Comment 1 Julien Nabet 2024-09-09 20:24:28 UTC
On pc Debian x86-64 with master sources updated today, I don't reproduce this.
I added an entry and LO generated 2 files:
<LO dir>/instdir/user/pack/autocorr/acor_fr-FR.pack
<LO dir>/instdir/user/autocorr/acor_fr-FR.dat
I didn't know the first one.

Anyway, I moved the second file in a new dir /tmp/autocorr
Then I changed the autocorrect path so it points towards /tmp/autocorr and it was OK.


If your acor_fr-FR.dat file doesn't contain private/sensitive data, would it be possible you zip and attach it to the bugtracker?
Comment 2 Constant 2024-09-10 16:27:43 UTC
Created attachment 196375 [details]
AutoCorrection French file edited
Comment 3 Constant 2024-09-10 16:32:59 UTC
I added the file in "Attachments" section. Tell me if you can replace your system file with it without having an empty list after restart. 

To verify if your LO reads the good list, you can try – after having configured the language in French – the word "fuchia" which should be replaced by "fuchsia" after a space.

The "During the writing" box (or similar formulation) has ofc to be checked.
Comment 4 Constant 2024-09-10 18:40:55 UTC
Messages from Yemisi on Ask (https://ask.libreoffice.org/t/desynchronisation-entre-fichier-dat-et-autocorrection/110446/5): "It is version 24.2.5.2 [and later] that pose[s] a problem. I have exactly the same bug since I installed this version [as well as 24.2.6.2]: the file exists, has not been overwritten by the version change, but the link does not work; we cannot re-create the list in French either - it does not save. I suppose that the file containing our autocorrections still exists but that it is a question of access path.

Note: by taking "replacements for the language" [all] we can add autocorrections again (but I did not find in which file it was copied) [and] the personal dictionary works."
Comment 5 Julien Nabet 2024-09-10 21:06:07 UTC
On pc Debian x86-64 with master sources updated today, I could reproduce this.

I noticed this on console:
warn:editeng:265912:265912:editeng/source/misc/svxacorr.cxx:2484: when loading file:///tmp/autocorrect/acor_fr-FR.dat com.sun.star.packages.zip.ZipIOException message: "/home/julien/lo/libreoffice/package/source/zippackage/ZipPackage.cxx:902: Bad Zip File, ZipException: Duplicate CEN entry (case insensitive) at /home/julien/lo/libreoffice/package/source/zipapi/ZipFile.cxx:1504 at /home/julien/lo/libreoffice/package/source/zippackage/ZipPackage.cxx:901" context: ZipPackage


acor_fr-FR.dat is in fact a zip file (you can rename the file to change .dat into .zip and you'll be able to unzip it).
The pb is LO considers there are duplicates when in insensitive case mode, eg:
'ad hoc'
'Ad hoc'

It needs more investigation.
Comment 6 Julien Nabet 2024-09-10 21:14:33 UTC
Michael: thought you might be interested in this one.
I wonder if StorageFormats::OFOPXML shouldn't be the only case when check is not case sensitive, at least this patch works:
diff --git a/package/source/zippackage/ZipPackage.cxx b/package/source/zippackage/ZipPackage.cxx
index 906acf4d7860..13144c1197a6 100644
--- a/package/source/zippackage/ZipPackage.cxx
+++ b/package/source/zippackage/ZipPackage.cxx
@@ -874,7 +874,7 @@ void SAL_CALL ZipPackage::initialize( const uno::Sequence< Any >& aArguments )
     {
         m_pZipFile.emplace(m_aMutexHolder, m_xContentStream, m_xContext, true,
             m_bForceRecovery,
-            m_nFormat == embed::StorageFormats::ZIP ? ZipFile::Checks::Default : ZipFile::Checks::CheckInsensitive);
+            m_nFormat == embed::StorageFormats::OFOPXML ? ZipFile::Checks::CheckInsensitive : ZipFile::Checks::Default);
         getZipFileContents();
     }
     catch ( IOException & e )
@@ -1248,7 +1248,7 @@ void ZipPackage::ConnectTo( const uno::Reference< io::XInputStream >& xInStream
     else
         m_pZipFile.emplace(m_aMutexHolder, m_xContentStream, m_xContext, false,
             false,
-            m_nFormat == embed::StorageFormats::ZIP ? ZipFile::Checks::Default : ZipFile::Checks::CheckInsensitive);
+            m_nFormat == embed::StorageFormats::OFOPXML ? ZipFile::Checks::CheckInsensitive : ZipFile::Checks::Default);
 }
 
 uno::Reference< io::XInputStream > ZipPackage::writeTempFile()
Comment 7 raal 2024-09-12 19:25:56 UTC
This seems to have begun at the below commit in bibisect repository/OS linux-64-24.8.
Adding Cc: to Michael Stahl ; Could you possibly take a look at this one?
Thanks
 44d61beb0a6985f855fe86b1f6698e14ac5e00a1 is the first bad commit
commit 44d61beb0a6985f855fe86b1f6698e14ac5e00a1
Author: Jenkins Build User <tdf@maggie.tdf>
Date:   Wed Jul 10 15:43:21 2024 +0200

    source 117824164632b6da636658fa52eae33a93dab3ce

170290: package: ZipFile: don't accept duplicate entries (case insensitive) | https://gerrit.libreoffice.org/c/core/+/170290
Comment 8 Commit Notification 2024-09-17 08:40:39 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/9012355a60bd88db582078e38123863a4959b72f

tdf#162866 package: fix loading AutoCorrect file with case-insensitive

It will be available in 25.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 9 Michael Stahl (allotropia) 2024-09-17 08:41:34 UTC
fixed on master
Comment 10 Commit Notification 2024-09-17 16:51:25 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "libreoffice-24-8":

https://git.libreoffice.org/core/commit/04a33cd368ab77c636160915e4ac4721b7e10c5e

tdf#162866 package: fix loading AutoCorrect file with case-insensitive

It will be available in 24.8.2.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 11 Commit Notification 2024-09-19 07:21:59 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "libreoffice-24-2":

https://git.libreoffice.org/core/commit/09c16904bbac8079428041e7802334c43395c8a6

tdf#162866 package: fix loading AutoCorrect file with case-insensitive

It will be available in 24.2.7.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.