Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cloning worksheet makes corrupted Xlsx #1516

Closed
marcopaggioro opened this issue Jun 7, 2020 · 8 comments
Closed

Cloning worksheet makes corrupted Xlsx #1516

marcopaggioro opened this issue Jun 7, 2020 · 8 comments

Comments

@marcopaggioro
Copy link

marcopaggioro commented Jun 7, 2020

This is:

- [X] a bug report
- [ ] a feature request
- [ ] **not** a usage question (ask them on https://stackoverflow.com/questions/tagged/phpspreadsheet or https://gitter.im/PHPOffice/PhpSpreadsheet)

What is the expected behavior?

With old versions of PHPSpreadsheet I was able to clone worksheets (as in the tutorial) and I was able to edit it correctly. For example if I opened an Xlsx file with one template worksheet I was able to clone it N times and every worksheet had different values.

What is the current behavior?

Now, if I try to clone a worksheet and save the Xlsx file it results corrupted.

What are the steps to reproduce?

Example file:
ReportStructure.xlsx

Code:

<?php

require __DIR__ . '/vendor/autoload.php';

use PhpOffice\PhpSpreadsheet\IOFactory;
use PhpOffice\PhpSpreadsheet\Shared\Date;
use PhpOffice\PhpSpreadsheet\Spreadsheet;
use PhpOffice\PhpSpreadsheet\Writer\Xlsx;

try {
    $spreadsheet = IOFactory::load("./ReportStructure.xlsx");
    $clonedSheet = clone $spreadsheet->getActiveSheet();
    $clonedSheet->setTitle("Example");
    $spreadsheet->addSheet($clonedSheet);
    
    $writer = new Xlsx($spreadsheet);
    $writer->save("Report.xlsx");
} catch (Exception $exception) {
    echo $exception;
}

Screen:
unknown
If I press "Si" (Yes), Excel crash

Which versions of PhpSpreadsheet and PHP are affected?

SpreadSheet: 5c18bb5 (1.13)
PHP: 7.3

@konovalovk
Copy link

Appeared in v 1.13. Previous release is not affected.

@oleibman
Copy link
Collaborator

oleibman commented Jun 9, 2020

This has to do with the change to ZipStream. Before and after, because of the clone, PhpSpreadsheet tries to write printerSettings1.bin to xl/printerSettings/. With the PHP Zip class, only one copy of this file is retained. But, with ZipStream, both copies are retained (I didn't even know that was possible), and that is the problem that Excel is having. I am not familiar with ZipStream,
and do not know how to fix this issue, but hopefully someone who is knowledgeable enough will see this comment.

@oleibman
Copy link
Collaborator

oleibman commented Jun 9, 2020

Omitted one word above.
... tries twice to write printerSettings1.bin ...

@agwidarsito
Copy link

Strange that two copies in the same path, with the same name, are being retained. Is that even a valid ZIP?

@kimbarcelona01
Copy link

Made this work by downgrading to v.1.11 for now. Lets wait for fixed release

@marcopaggioro
Copy link
Author

@kimbarcelona01 Unfortunately, version 1.11 as well as 1.12 have a bug regarding the Drawer which is fixed in 1.13

MarkBaker pushed a commit that referenced this issue Jun 19, 2020
This problem is that ZipStream, in contrast to ZipArchive,
is saving 2 files with the same path. I have opened an issue with
ZipStream, who agree that this appears to be a bug.

For the case in question, PhpSpreadsheet is attempting to save
a file with the same path twice (and unexpectedly succeeding)
because of a clone operation. This fix attempts to rectify the problem
by keeping track of all the paths being saved in the zip file,
and not attempting to save any duplicate paths.

The problem case attempted to save printersettings1.bin twice,
but there are other possible exposures, e.g. by cloning a sheet
with a drawing.The new test cases clone an existing sample which
has both printer settings and drawings.
@stale
Copy link

stale bot commented Aug 16, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.
If this is still an issue for you, please try to help by debugging it further and sharing your results.
Thank you for your contributions.

@stale stale bot added the stale label Aug 16, 2020
@stale stale bot closed this as completed Aug 23, 2020
@oleibman
Copy link
Collaborator

Fixed by PR #1530 in June 2020.

@oleibman oleibman removed the stale label Jul 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

5 participants