[Libreoffice-commits] core.git: Branch 'libreoffice-5-1' - framework/source
framework/source/services/autorecovery.cxx | 13 + 1 file changed, 13 insertions(+) New commits: commit e3759a3154de534a5edfd69f7face5b5c29c1ea9 Author: anwilli5 <anwil...@ncsu.edu> Date: Sun Jun 5 23:06:05 2016 -0400 tdf#96607 'Save as' doesn't update global auto-recovery state The auto-recovery service maintains a list of structures (one for each open document) containing information needed to carry out the auto-save functionality. One such piece of information is the location of the backup file, stored in a struct member named 'OldTempURL'. At every auto-save interval, this list is iterated through and a function (implts_saveOneDoc) is called during each iteration to save the current state of the associated document. The algorithm works as follows: 1. A new backup file URL is chosen so as not to conflict with any already existing backup files in the backup directory. This URL is based on the file name and incorporates a number (starting at 0) that is incremented until a name is chosen that doesn't conflict. 2. The document is saved to this new backup file URL 3. The previous backup file (indicated by its structure's 'OldTempURL') is deleted 4. The new backup file URL is stored (in its structure's 'OldTempURL') for the next time the file needs to be saved. Assuming you start with a new Writer doc and then make some changes, when it is time to auto-save, the backup file name 'untitled_0.odt' (excluding path) will be selected, the latest state of the open file will be written to that backup file, and the full URL for the backup file will be saved into the struct 'OldTempURL' member. The next time changes are made and an auto-save occurs, this algorithm will result in the name 'untitled_1.odt' being selected, the file contents saved into this new file, 'untitled_0.odt' being deleted, and the full URL for the new backup file being saved in 'OldTempURL'. The third time through results in 'untitled_0.odt' being selected (since this file doesn't exist on disk), and subsequent iterations of auto-saving cause the backup file name to alternate between the two aforementioned. The problem occurs during a 'Save as' operation. When this happens, the backup file is deleted (which is fine - it was just saved, and the next auto-save will back it up) but 'OldTempURL' is not properly reset (see below for more info.) During the next auto-save, 'untitled_0.odt' will be selected for the new backup file name (since no file exists by this name), and one of two things will happen (based on how many auto-saves have occurred): 1. 'OldTempURL' points to 'untitled_1.odt', and the algorithm above continues to work correctly (at least in that it continues to backup file contents.) 2. 'OldTempURL' points to 'untitled_0.odt', the name chosen for the new backup file. In this case, the document contents will be saved to this file (step 2) but then the file will be deleted (step 3). 'OldTempURL' will maintain this URL from then on out, causing this case to be hit for all future auto-save intervals. So, 50% of the time (30 minutes out of every hour) auto-save will stop backing up file contents on a 'Save as'. The function that handles the 'Save as' case (implts_markDocumentAsSaved) clears 'OldTempURL' and sets other relavent struct members for a local variable copy of the global struct, but doesn't copy them back. :( These changes are effectively lost when the function returns. There are several other cases where this appears to be happening as well, but more work is needed to determine whether this is actually the case: - implts_prepareSessionShutdown - implts_saveDocs, handling the 'dangerousDocs' and in a few other places - implts_openDocs - implts_resetHandleStates Also, there is some JUnitTest code for auto-save, but it is currently disabled (and fails to run successfully.) It'd be great to get these working again, or to just write python equivalents. Implementing this would like take me a while, though, so for now I just tested manually to ensure that this fixes the issue. When I have some more time I'd like to work more on this, but I wanted to send this patch in for now to address bug #96607. This may also address bug #99890, since some of the struct members that don't make it into the global state relate to the file name. I haven't explicitly tested this case, though. Change-Id: Ic702d6f78e60c7cf828a1564ccca118dd45d152b Reviewed-on: https://gerrit.libreoffice.org/25948 Tested-by: Jenkins <c...@libreoffice.org> Reviewed-by: jan iversen <j...@documentfoundation.or
[Libreoffice-commits] core.git: Branch 'distro/collabora/lov-5.2' - 10 commits - framework/source package/source sc/source svl/source sw/source vcl/source vcl/unx xmloff/source
framework/source/accelerators/acceleratorconfiguration.cxx |9 +++- framework/source/accelerators/presethandler.cxx| 24 ++--- framework/source/inc/accelerators/presethandler.hxx|3 + framework/source/services/autorecovery.cxx | 13 +++ package/source/manifest/ManifestDefines.hxx|4 +- package/source/manifest/ManifestExport.cxx |4 +- package/source/manifest/ManifestImport.cxx |3 + package/source/manifest/ManifestImport.hxx |1 sc/source/core/data/column4.cxx| 14 +++ sc/source/core/tool/interpr4.cxx | 15 ++-- svl/source/numbers/numfmuno.cxx|2 - sw/source/ui/misc/bookmark.cxx | 12 +++--- sw/source/uibase/inc/bookmark.hxx |1 vcl/source/control/edit.cxx|5 ++ vcl/source/edit/vclmedit.cxx |7 --- vcl/source/window/window2.cxx |2 - vcl/unx/generic/gdi/x11cairotextrender.cxx | 23 xmloff/source/forms/propertyimport.cxx | 11 + 18 files changed, 94 insertions(+), 59 deletions(-) New commits: commit 9e47646c34905a0ac41c12763eb90cfa01ca88a4 Author: anwilli5 <anwil...@ncsu.edu> Date: Sun Jun 5 23:06:05 2016 -0400 tdf#96607 'Save as' doesn't update global auto-recovery state The auto-recovery service maintains a list of structures (one for each open document) containing information needed to carry out the auto-save functionality. One such piece of information is the location of the backup file, stored in a struct member named 'OldTempURL'. At every auto-save interval, this list is iterated through and a function (implts_saveOneDoc) is called during each iteration to save the current state of the associated document. The algorithm works as follows: 1. A new backup file URL is chosen so as not to conflict with any already existing backup files in the backup directory. This URL is based on the file name and incorporates a number (starting at 0) that is incremented until a name is chosen that doesn't conflict. 2. The document is saved to this new backup file URL 3. The previous backup file (indicated by its structure's 'OldTempURL') is deleted 4. The new backup file URL is stored (in its structure's 'OldTempURL') for the next time the file needs to be saved. Assuming you start with a new Writer doc and then make some changes, when it is time to auto-save, the backup file name 'untitled_0.odt' (excluding path) will be selected, the latest state of the open file will be written to that backup file, and the full URL for the backup file will be saved into the struct 'OldTempURL' member. The next time changes are made and an auto-save occurs, this algorithm will result in the name 'untitled_1.odt' being selected, the file contents saved into this new file, 'untitled_0.odt' being deleted, and the full URL for the new backup file being saved in 'OldTempURL'. The third time through results in 'untitled_0.odt' being selected (since this file doesn't exist on disk), and subsequent iterations of auto-saving cause the backup file name to alternate between the two aforementioned. The problem occurs during a 'Save as' operation. When this happens, the backup file is deleted (which is fine - it was just saved, and the next auto-save will back it up) but 'OldTempURL' is not properly reset (see below for more info.) During the next auto-save, 'untitled_0.odt' will be selected for the new backup file name (since no file exists by this name), and one of two things will happen (based on how many auto-saves have occurred): 1. 'OldTempURL' points to 'untitled_1.odt', and the algorithm above continues to work correctly (at least in that it continues to backup file contents.) 2. 'OldTempURL' points to 'untitled_0.odt', the name chosen for the new backup file. In this case, the document contents will be saved to this file (step 2) but then the file will be deleted (step 3). 'OldTempURL' will maintain this URL from then on out, causing this case to be hit for all future auto-save intervals. So, 50% of the time (30 minutes out of every hour) auto-save will stop backing up file contents on a 'Save as'. The function that handles the 'Save as' case (implts_markDocumentAsSaved) clears 'OldTempURL' and sets other relavent struct members for a local variable copy of the global struct, but doesn't copy them back. :( These changes are effectively lost when the fu
[Libreoffice-commits] core.git: Branch 'libreoffice-5-2' - framework/source
framework/source/services/autorecovery.cxx | 13 + 1 file changed, 13 insertions(+) New commits: commit 1647335fddabb1e31d6c9a41b3dc2aca31d86a9d Author: anwilli5 <anwil...@ncsu.edu> Date: Sun Jun 5 23:06:05 2016 -0400 tdf#96607 'Save as' doesn't update global auto-recovery state The auto-recovery service maintains a list of structures (one for each open document) containing information needed to carry out the auto-save functionality. One such piece of information is the location of the backup file, stored in a struct member named 'OldTempURL'. At every auto-save interval, this list is iterated through and a function (implts_saveOneDoc) is called during each iteration to save the current state of the associated document. The algorithm works as follows: 1. A new backup file URL is chosen so as not to conflict with any already existing backup files in the backup directory. This URL is based on the file name and incorporates a number (starting at 0) that is incremented until a name is chosen that doesn't conflict. 2. The document is saved to this new backup file URL 3. The previous backup file (indicated by its structure's 'OldTempURL') is deleted 4. The new backup file URL is stored (in its structure's 'OldTempURL') for the next time the file needs to be saved. Assuming you start with a new Writer doc and then make some changes, when it is time to auto-save, the backup file name 'untitled_0.odt' (excluding path) will be selected, the latest state of the open file will be written to that backup file, and the full URL for the backup file will be saved into the struct 'OldTempURL' member. The next time changes are made and an auto-save occurs, this algorithm will result in the name 'untitled_1.odt' being selected, the file contents saved into this new file, 'untitled_0.odt' being deleted, and the full URL for the new backup file being saved in 'OldTempURL'. The third time through results in 'untitled_0.odt' being selected (since this file doesn't exist on disk), and subsequent iterations of auto-saving cause the backup file name to alternate between the two aforementioned. The problem occurs during a 'Save as' operation. When this happens, the backup file is deleted (which is fine - it was just saved, and the next auto-save will back it up) but 'OldTempURL' is not properly reset (see below for more info.) During the next auto-save, 'untitled_0.odt' will be selected for the new backup file name (since no file exists by this name), and one of two things will happen (based on how many auto-saves have occurred): 1. 'OldTempURL' points to 'untitled_1.odt', and the algorithm above continues to work correctly (at least in that it continues to backup file contents.) 2. 'OldTempURL' points to 'untitled_0.odt', the name chosen for the new backup file. In this case, the document contents will be saved to this file (step 2) but then the file will be deleted (step 3). 'OldTempURL' will maintain this URL from then on out, causing this case to be hit for all future auto-save intervals. So, 50% of the time (30 minutes out of every hour) auto-save will stop backing up file contents on a 'Save as'. The function that handles the 'Save as' case (implts_markDocumentAsSaved) clears 'OldTempURL' and sets other relavent struct members for a local variable copy of the global struct, but doesn't copy them back. :( These changes are effectively lost when the function returns. There are several other cases where this appears to be happening as well, but more work is needed to determine whether this is actually the case: - implts_prepareSessionShutdown - implts_saveDocs, handling the 'dangerousDocs' and in a few other places - implts_openDocs - implts_resetHandleStates Also, there is some JUnitTest code for auto-save, but it is currently disabled (and fails to run successfully.) It'd be great to get these working again, or to just write python equivalents. Implementing this would like take me a while, though, so for now I just tested manually to ensure that this fixes the issue. When I have some more time I'd like to work more on this, but I wanted to send this patch in for now to address bug #96607. This may also address bug #99890, since some of the struct members that don't make it into the global state relate to the file name. I haven't explicitly tested this case, though. Change-Id: Ic702d6f78e60c7cf828a1564ccca118dd45d152b Reviewed-on: https://gerrit.libreoffice.org/25948 Tested-by: Jenkins <c...@libreoffice.org> Reviewed-by: jan iversen <j...@documentfoundation.or
[Libreoffice-commits] core.git: framework/source
framework/source/services/autorecovery.cxx | 13 + 1 file changed, 13 insertions(+) New commits: commit 9e28b2f9ac3f205db223352cb88eb3546a8e1c0e Author: anwilli5 <anwil...@ncsu.edu> Date: Sun Jun 5 23:06:05 2016 -0400 tdf#96607 'Save as' doesn't update global auto-recovery state The auto-recovery service maintains a list of structures (one for each open document) containing information needed to carry out the auto-save functionality. One such piece of information is the location of the backup file, stored in a struct member named 'OldTempURL'. At every auto-save interval, this list is iterated through and a function (implts_saveOneDoc) is called during each iteration to save the current state of the associated document. The algorithm works as follows: 1. A new backup file URL is chosen so as not to conflict with any already existing backup files in the backup directory. This URL is based on the file name and incorporates a number (starting at 0) that is incremented until a name is chosen that doesn't conflict. 2. The document is saved to this new backup file URL 3. The previous backup file (indicated by its structure's 'OldTempURL') is deleted 4. The new backup file URL is stored (in its structure's 'OldTempURL') for the next time the file needs to be saved. Assuming you start with a new Writer doc and then make some changes, when it is time to auto-save, the backup file name 'untitled_0.odt' (excluding path) will be selected, the latest state of the open file will be written to that backup file, and the full URL for the backup file will be saved into the struct 'OldTempURL' member. The next time changes are made and an auto-save occurs, this algorithm will result in the name 'untitled_1.odt' being selected, the file contents saved into this new file, 'untitled_0.odt' being deleted, and the full URL for the new backup file being saved in 'OldTempURL'. The third time through results in 'untitled_0.odt' being selected (since this file doesn't exist on disk), and subsequent iterations of auto-saving cause the backup file name to alternate between the two aforementioned. The problem occurs during a 'Save as' operation. When this happens, the backup file is deleted (which is fine - it was just saved, and the next auto-save will back it up) but 'OldTempURL' is not properly reset (see below for more info.) During the next auto-save, 'untitled_0.odt' will be selected for the new backup file name (since no file exists by this name), and one of two things will happen (based on how many auto-saves have occurred): 1. 'OldTempURL' points to 'untitled_1.odt', and the algorithm above continues to work correctly (at least in that it continues to backup file contents.) 2. 'OldTempURL' points to 'untitled_0.odt', the name chosen for the new backup file. In this case, the document contents will be saved to this file (step 2) but then the file will be deleted (step 3). 'OldTempURL' will maintain this URL from then on out, causing this case to be hit for all future auto-save intervals. So, 50% of the time (30 minutes out of every hour) auto-save will stop backing up file contents on a 'Save as'. The function that handles the 'Save as' case (implts_markDocumentAsSaved) clears 'OldTempURL' and sets other relavent struct members for a local variable copy of the global struct, but doesn't copy them back. :( These changes are effectively lost when the function returns. There are several other cases where this appears to be happening as well, but more work is needed to determine whether this is actually the case: - implts_prepareSessionShutdown - implts_saveDocs, handling the 'dangerousDocs' and in a few other places - implts_openDocs - implts_resetHandleStates Also, there is some JUnitTest code for auto-save, but it is currently disabled (and fails to run successfully.) It'd be great to get these working again, or to just write python equivalents. Implementing this would like take me a while, though, so for now I just tested manually to ensure that this fixes the issue. When I have some more time I'd like to work more on this, but I wanted to send this patch in for now to address bug #96607. This may also address bug #99890, since some of the struct members that don't make it into the global state relate to the file name. I haven't explicitly tested this case, though. Change-Id: Ic702d6f78e60c7cf828a1564ccca118dd45d152b Reviewed-on: https://gerrit.libreoffice.org/25948 Tested-by: Jenkins <c...@libreoffice.org> Reviewed-by: jan iversen <j...@documentfoundation.o
