Bug 124537 - Editing password-protected XLS created multiple empty files in backup directory
Summary: Editing password-protected XLS created multiple empty files in backup directory
Status: RESOLVED DUPLICATE of bug 118639
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
4.3.0.4 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisectRequest, regression
Depends on:
Blocks: AutoSave-AutoRecovery-Backup Password-Protected XLS
  Show dependency treegraph
 
Reported: 2019-04-03 20:36 UTC by Mike Kaganski
Modified: 2019-04-15 07:05 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Kaganski 2019-04-03 20:36:26 UTC
0. Set auto-save frequency to 1 minute (for faster reproduction);
1. Open user profile's backup directory (e.g., on Windows it's C:\Users\<username>\AppData\Roaming\LibreOffice\4\user\backup) in a file manager to see its changing content;
2. Create a new spreadsheet; save it as XLS (97-2003) with a password (e.g., as "pwd_backup_proliferation.xls");
3. Make an edit to mark it modified;
4. Wait 1 minute and let auto-save to trigger.

In the backup directory, empty (0-byte) files start to appear ~every 5-10 s, named like this: pwd_backup_proliferation.xls_0.ods; pwd_backup_proliferation.xls_1.ods, ... etc. Closing the file does not remove the generated files.

The impact is not only proliferation of empty files in the directory, but also backup save not working for password-protected XLS files.

Reproducible with Version: 4.3.0.4
Build ID: 62ad5818884a2fc2e5780dd45466868d41009ec0
(there files were named slightly differently: pwd_backup_proliferation.xls_0ods)

and with Version: 6.2.3.1 (x64)
Build ID: 9ba025bafb03b962c34687cf87806cc03a3a7436
CPU threads: 12; OS: Windows 10.0; UI render: GL; VCL: win; 
Locale: ru-RU (ru_RU); UI-Language: en-US
Calc: CL

In Version: 4.2.0.4
Build ID: 05dceb5d363845f2cf968344d7adab8dcfb2ba71
it works OK: it creates a single file ~10 KB. Closing the file removes the backup.
Comment 1 Mike Kaganski 2019-04-03 20:45:01 UTC
Just tested to also affect DOC format.
Comment 2 Mike Kaganski 2019-04-03 20:49:07 UTC
... and with XLSX. Looks like common problem for all (?) foreign formats.
Comment 3 Mike Kaganski 2019-04-03 21:44:58 UTC
The problem seems to be in ZipPackage::setPropertyValue, where it expects "PackageSHA256UTF8EncryptionKey" or "PackageSHA1UTF8EncryptionKey", but actually gets "OOXPassword" (for XLSX) or "STD97EncryptionKey"/"STD97UniqueID" pair (for XLS).

The debug output lists these lines for each attempt:

> warn:sfx.doc:16096:17588:sfx2/source/doc/docfile.cxx:881: It must be possible to set a common password for the storage
> warn:sfx.doc:16096:17588:sfx2/source/doc/objstor.cxx:1378: Setting of common encryption key failed!
Comment 4 Buovjaga 2019-04-15 06:57:55 UTC
Looks like a dupe of bug 118639
Comment 5 Mike Kaganski 2019-04-15 07:05:01 UTC

*** This bug has been marked as a duplicate of bug 118639 ***