Description: When I open a JPG and then export as JPG the result is a zero byte file. This only happens when I overwrite to the original file name. I have repeated this in several tests with different files. Steps to Reproduce: 1.Open a JPG file 2.Export as JPG using the original file name 3.Agree to overwrite (per file exists warning) Actual Results: Output file is corrupted - byte size is zero Expected Results: Overwrite the original file with the modified version Reproducible: Always User Profile Reset: No Additional Info: Version: 7.1.6.2 (x64) / LibreOffice Community Build ID: 0e133318fcee89abacd6a7d077e292f1145735c3 CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
In LO 6.2 error dialog "Writer error. File could not be written". Repro LO 6.3 and 7.3+ Windows and Linux. In Linux 6.2 and 6.3 and 6.4 master there's a crash on save, so bibisect should be done in Windows.
May be the same bug: when PNG Options appear, see size, click in Resolution field, see that size becomes 0.
Should the wanted behaviour be similar for example to the GIMP's export tool? It overwrites the file that has a same name. Or is it enough to show an error dialog and leave the file intact?
I think the current message dialog is proper. That is: "filename.jpg already exists. Do you want to replace it?" But presently, if you reply "yes" to overwrite, you get a zero byte file.
Assuming there may be good reasons to avoid overwriting the open file, a good alternative might be changing the message box to something like: "filename.jpg already exists - choose a new filename."
Dear Daniel Baran, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Per QA Team request: Using the version below, I still see the same behavior. If I export to a new filename, the file is good. If I export to the same filename the file is zero bytes. Hope this helps. Version: 7.5.6.2 (X86_64) / LibreOffice Community Build ID: f654817fb68d6d4600d7d2f6b647e47729f55f15 CPU threads: 12; OS: Windows 10.0 Build 22621; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
Adding: I'm seeing the same behavior in the following versions as well. Export to a new filename, the file is good. Export to the same filename the file is zero bytes. Version: 7.5.7.1 (X86_64) / LibreOffice Community Build ID: 47eb0cf7efbacdee9b19ae25d6752381ede23126 CPU threads: 12; OS: Windows 10.0 Build 22621; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded Version: 7.6.2.1 (X86_64) / LibreOffice Community Build ID: 56f7684011345957bbf33a7ee678afaf4d2ba333 CPU threads: 12; OS: Windows 10.0 Build 22621; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
reproduced with recent trunk build: Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: a1a1d8edb9d4a62b747aa7069b3026e2ba75704d CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded
Issue reproduced with Version: 24.2.5.2 (X86_64) / LibreOffice Community Build ID: 420(Build:2) CPU threads: 2; OS: Linux 6.9; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US 24.2.5-1 Calc: threaded Referring to the Steps to Reproduce from the description (comment#0) 1.Open a JPG file. Initially, there was no lock file. After the file got opened, the lock file appeared. 2.Export as JPG using the original file name 3.Agree to overwrite (per file exists warning). In my case, after the pop up window to confirm over writing an existing file, I also had a pop up window to set some aspects of the way the image would be saved. After I agreed to the default suggestions, the lock file disappeared, and the file got truncated to 0 (zero) size.
Referring to my own comment#10: I used the words aspects how the image would be saved. A better choice of words is aspects how the image would be exported. Issue reproduced with Version: 24.2.5.2 (X86_64) / LibreOffice Community Build ID: 420(Build:2) CPU threads: 2; OS: Linux 6.9; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US 24.2.5-1 Calc: threaded Referring to the Steps to Reproduce from the description (comment#0) 1.Open a JPG file. Initially, there was no lock file. After the file got opened, the lock file appeared. 2.Export as JPG using the original file name 3.Agree to overwrite (per file exists warning). In my case, after the pop up window to confirm over writing an existing file, I also had a pop up window to set some aspects of the way the image would be exported. After I agreed to the default suggestions, the lock file disappeared, and the file got truncated to 0 (zero) size.
Bibisected the commit that made the switch from error message to 0-byte export with linux-64-6.3: commit 6a58859bf24c949e2531fffe5e999bcc868414c8 author Caolán McNamara Thu Feb 07 10:29:45 2019 +0000 committer Caolán McNamara Thu Feb 07 13:28:53 2019 +0100 Resolves: rhbz#1673198 cannot overwrite open file with export this reverts commit 3c4cfa209f446fc433c8d3925cbbe628c2f536e8 Date: Mon Nov 26 12:51:05 2007 +0000 INTEGRATION: CWS fwk72 (1.195.14); FILE MERGED 2007/09/10 14:55:01 mav 1.195.14.1: #i81437# do not allow to export to the file the document is based on Reviewed-on: https://gerrit.libreoffice.org/67491 Not mentioned in the commit message, that fixed bug 103947. Caolán, what do you think?