tested on Win7 64bit with Version: 4.2.0.0.alpha0+ Build ID: 2382b8e8ec0ea65dc2a9ad1c401abe3be35a1487 TinderBox: Win-x86@6-debug, Branch:master, Time: 2013-08-02_23:15:16 Steps to reproduce: 1- load the autocorrect replacement table (Tools/Autocorrect options/Replace) 2- insert a custom autocorrect entry in the "replace" and "with" fields 3- click "new" and "ok" buttons to save the new addition 4- reopen the replacement table Expected behaviour: the new added entry should be part of the list. Current behaviour: the new added entry is not present. it seems that saving new entries in the autocorrect replacement table is broken. it works fine in 4.0.4 and 4.1.0 final release. adding to the mab4.2 list since an important functionality is not working anymore.
Hi tommy27, thanks for reporting. I can not reproduce with: Win7x64i3Ultimate Version: 4.2.0.0.alpha0+ Build ID: aa5683e18de07c9e86325595ead4574efa685c3a TinderBox: Win-x86@6-debug, Branch:master, Time: 2013-08-04_00:00:18 Have you tried resetting the user profile?. What do you enter in "replace" and in "with". Before a confirmation changed the status to medium and normal.
still having the same issue with clean profile on Win7 64bit and a new master build. Version: 4.2.0.0.alpha0+ Build ID: aa5683e18de07c9e86325595ead4574efa685c3a TinderBox: Win-x86@6-debug, Branch:master, Time: 2013-08-04_00:00:18
We need some else take a look to this report, and verify the issue. So changed the status to unconfirmed.
I installed 4.2alpha twice (2 different builds) and in each case the user profile was clean. browsing the user folder I see that no autocorr subfolder exists and even if you try adding new autocorrect entries that folder is not created. if you manually copy the autocorr subfolder from another user profile and put it inside the 4.2dev user folder, then autocorrect entries can be saved and stored regularly. from what I see, the issue is that LOdev fails to create a new autocorr subfolder if no such folder is already present.
*** Bug 67765 has been marked as a duplicate of this bug. ***
4.2alpha can't store new autocorrect entries. 4.1.0.4 can store new autocorrect entries but unlike previous releases, custom autocorrect entries are not stored in user profile "...User\LibreOffice 4\user\autocorr" (this subfolder is not created in the user profile) it seems that new autocorrect entries stay in default autocorrect databases stored in "...Bin\LibreOffice 4\share\autocorr" I don't know if this is intended or not... however even if autocorrect works in 4.1.x the location is not correct... that stuff must stay in the user profile to allow future migration of those data. do I need to file a separate bug report regarding this?
I am not sure that Bug 66765 is a dupe of this. This one is about 4.2 alpha under Windows, and that is about 4.1 under Linux. And I cannot reproduce the bug 66765 under Win7x64 with 4.1.0.4. Further, as far as I can tell, the autocorrection database for 4.1 is stored (at least in my system) in "%userprofile%\AppData\Roaming\LibreOffice\4\user\autocorr". So, I suggest: 1. Mark Bug 66765 as UNCONFIRMED again (until it is confirmed by some Linux user). 2. File a distinct bug report about some installations of 4.1 in Windows where the autocorrection DB is stored in wrong path. 3. Mark these three bugs as see also to each other.
@Mike 1- the correct number for the duplicate bug you are talking about is Bug 67765 2- maybe you are right... we are probably dealing with linked yet different issues in different OS 3- the correct user profile path in Win7 is ""%userprofile%\AppData\Roaming\LibreOffice\4\user\autocorr" the path I gave is that of the portable version. could you please try to replicate the issue I saw? you should temporarily delete the autocorr subfolder from your profile, then enter some new entries in the replacemente table and see if LibO 4.1 creates a new autocorr folder in the user profile. in my system it fails doing so unless an autocorr folder is already present
I can confirm this bug with both 4.1.0.4 and 4.2.0.0.alpha0+ (Build ID: acdf00ea9995ba06b18c0b0ea0eb55974f1e3ae9 TinderBox: Win-x86@6-debug, Branch:master, Time: 2013-08-06_07:23:57), both on Windows 7 32-bit. Unlike what was said by tommy27, I can't see any difference between the both. So I'm also changing the 'Version' field to 4.1.0.4. Currently, two workarounds exist: 1) Run LibreOffice as Administrator. (In this case the values stored in %ProgramFiles%\LibreOffice 4\share\autocorr. You can see it by the last modification date, and you can also unzip the files and see your saved values.) 2) Manually create %USERPROFILE%\AppData\Roaming\LibreOffice\4\user\autocorr, and copy there the file for the language you want (Without copying the files there it won't work, even if the directory exist).
@tommy27: I see that for 4.1.0.4 testing you used the portable version. If this is true, then you can't compare it with 4.2.0alpha, because the latter installs in %ProgramFiles% folder which is non-writable by an ordinary user (only by Administrator, that explains the first workaround from my previous comment). @Mike Kaganski: Maybe you have the UAC disabled?
Reproductible on Linux too (4.1.0.4 from libreoffice.org, on Ubuntu 13.04 64-bit), including the two workarounds. So I'm pretty sure it's the same issue. @Mike Kaganski: The fact you can't reproduce on Windows, can be also explained if you left your LO profile after uninstalling an older version.
I'm downloading right now 4.1.0 final to test on a standard install version (not portable). it seems that the problem comes out when LibO has to create a brand new autocorrect folder, while it can work with no issue if it finds such folder from previous installation
(In reply to comment #8) > 1- the correct number for the duplicate bug you are talking about is Bug > 67765 Thank you. My guilty :) (In reply to comment #11) > @Mike Kaganski: The fact you can't reproduce on Windows, can be also > explained if you left your LO profile after uninstalling an older version. You are quite right. I can confirm this with 4.1.0.4 under Win7x64. -LO creates fresh new user profule without autocorr directory. -If absent, this directory is not created on Autocorrection entry addition. -If this directory is present, and the required language file is absent in it, it is not created by program. -If used under admin, LO stores autocorrection entries in its main autocorrection db, if conditions above are true. So, please ignore my Comment 7.
I confirm issue on standard installation of LibO 4.1.0.4 with same behaviour reported on 4.2alpha (interestingly the portable version from winPenPack was able to store new entries but not inside the user profile folder). description of the bug in Comment 13 is pretty accurate. I'm moving this bug from mab4.2 to mab4.1 and set higher importance values. autocorrect function is completely unusable for new user who don't have a preexisting profile.
adding REGRESSION keyword since it works fine in 4.0.x branch changing version field according to Bug 67765 description: the issue is already reported in 4.1.0.3 rc but I suspect the bug came out in earlier development 4.1.x releases... can any Linux user try to bibisect this?
My guess is that the root of the problem is that LibO fails to create a brand new autocorr folder in the right location which is inside the user profile (the Windows path is: C:\Users\YourName\AppData\Roaming\LibreOffice\4\user\autocorr If my theory is right, LibO tries instead to save it inside C:\Program Files (x86)\LibreOffice 4\share\autocorr but fails to overwrite the acor.dat files since they are located in a Windows system folder where overwriting is not allowed. This is indirectly confirmed by the fact that the portable version X-LibO from winPenPack doesn't save data in the “X-LibreOffice\User\autocorr” folder as well but it's able to store the new autocorrection data inside “X-LibreOffice\Bin/share/autocorr” which is not protected unlike the standard non-portable version. The weird thing as other user reported is that LibO correctly saves autocorrection data in the user profile if that subfolder was already present from a previous installation.
Caolan McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=d2c3297eed9917c110da67b2a4c19265aecb38ed Resolves: fdo#67743 user autocorr file not written The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
fixed in master, proposed for 4-1 in gerrit
Caolan McNamara committed a patch related to this issue. It has been pushed to "libreoffice-4-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=447c22283f7e7d592a5653925f9c1bbc7fa3766a&h=libreoffice-4-1 Resolves: fdo#67743 user autocorr file not written It will be available in LibreOffice 4.1.2. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
great fix Caolan. I hope it will make it for 4.1.1 as well.
I'm just a user and hit this bug right away in 4.1.0.4 I just installed on a Win7 machine. Good job of pinning it down! I created an autocorr folder where it belonged and copied my language file from Program Files\... to that folder and my autocorrects are now saved! -Marco Polo (In reply to comment #16) > My guess is that the root of the problem is that LibO fails to create a > brand new autocorr folder in the right location which is inside the user > profile (the Windows path is: > C:\Users\YourName\AppData\Roaming\LibreOffice\4\user\autocorr > > If my theory is right, LibO tries instead to save it inside C:\Program Files > (x86)\LibreOffice 4\share\autocorr but fails to overwrite the acor.dat > files since they are located in a Windows system folder where overwriting is > not allowed. > > This is indirectly confirmed by the fact that the portable version X-LibO > from winPenPack doesn't save data in the “X-LibreOffice\User\autocorr” > folder as well but it's able to store the new autocorrection data inside > “X-LibreOffice\Bin/share/autocorr” which is not protected unlike the > standard non-portable version. > > The weird thing as other user reported is that LibO correctly saves > autocorrection data in the user profile if that subfolder was already > present from a previous installation.
@Marco Polo yes. manual copy is a workaround to make autocorrect work again. the bug only happens if that folder is empty at first installation.
@Caolan McNamara sorry, I don't wanna seem pushy but IMHO this bug should be applied to 4.1.1 as well. old user can easily workaround this issue, using their old profiles, but new user will face an unusable autocorrect engine.
So how do I get the "autocorrect engine" to work on the installation of LibreOffice that I have installed on my computer? Do I need to uninstall the newest version, then install an older version, then add my autocorrect entries, then install the newest version of LibreOffice? Is there a simpler way to do this?
if you had a previous LibO version installed on your PC the old autocorrect data should be preserved in the user profile and be correctly managed by LibO 4.1.0 if 4.1.0 is your first LibO installation you just have to manually copy the autocorr folder from C:\Program Files (x86)\LibreOffice 4\share\autocorr to C:\Users\YourName\AppData\Roaming\LibreOffice\4\user\autocorr
Alas, I'm not using the Windows version of LibreOffice, I'm using the GNU/Linux version of LibreOffice. Never mind all this. I'll just wait for the next release to fix the problem.
(In reply to comment #27) > Alas, I'm not using the Windows version of LibreOffice, I'm using the > GNU/Linux version of LibreOffice. > > Never mind all this. I'll just wait for the next release to fix the problem. the Linux location of the user profile is here: https://wiki.documentfoundation.org/UserProfile#GNU.2FLinux do the same manual copy&paste I described for Windows. it should work.
mostly fixed but there is still one problem here... the very first time with a new user profile, add an autocorrect entry as in "description", then it will work when typing the letters, but then open the "AutoCorrect Options" dialog again and the new entry is no longer there. subsequently added entries stick around. this works in libreoffice-4-0, so part of the regression i guess.
Caolan McNamara committed a patch related to this issue. It has been pushed to "libreoffice-4-1-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=bf369b2c653297d722d41e56fd71425526a44a72&h=libreoffice-4-1-1 Resolves: fdo#67743 user autocorr file not written It will be available already in LibreOffice 4.1.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 68520 has been marked as a duplicate of this bug. ***
@Caolán McNamara: I can confirm comment 29: With 4.1.1.2 using new user profile, either adding or removing items from the autocorrect list works only until next time you open the autocorrect dialog. Then even if you click 'Cancel' or just close the window, it reverts your changes. Same happens if you just close LO completely and reopen. Only second time changes are saved. Verified on Windows 7 (32-bit). Would be great if you could take a look at this. thanks.
Caolan McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=68dea1c1b61a99cdef556ba7d8ccfdad1be8a663 Resolves: fdo#67743 ensure user autocorr config dir exists The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Caolan McNamara committed a patch related to this issue. It has been pushed to "libreoffice-4-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=ef0a7a309d03c83f59a32595132f3f3e4c9893c0&h=libreoffice-4-1 Resolves: fdo#67743 ensure user autocorr config dir exists It will be available in LibreOffice 4.1.2. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I confirm that everything is fixed in Version: 4.2.0.0.alpha0+ Build ID: 94730f359023a3e90fd6d5239a12a150f41f4dd2 TinderBox: Win-x86@39, Branch:master, Time: 2013-08-31_03:30:4
*** Bug 68860 has been marked as a duplicate of this bug. ***