Closed yulqen closed 3 years ago
Hi Matt, its possible that this issue is caused when openpyxl opens/creates a document, but then doesn't have the chance to save it.
When I tired running this doc through bcompiler I go an error message stating at end 'zipfile.BadZipFile:file is not a zip file', which is the same error message I get (in pycharm) for those files that I have created through other programmes (using openpyxl), but I have stopped the programme before completion and openpyxl has therefore not had the opportunity to save the output. Not fully sure if this is the correct assessment of what's going on.
Its possible that bcompiler was stopped, before it had the chance to save this file? although not sure if bcompiler is able to do that though?
Hey @banillie! Yeah, that's entirely possible. I'd need to test.
Was there a reason why you had to stop the write process before completion in your scripts? (Was it because it was taking too long, or appearing to hang, or something else?) If, when bcompiler
is creating the file it's entirely possible that something would stop the process completely, but I would have thought you would have been alerted and the file would not have been created. Maybe not though - I'd need to refamiliarise myself with how this aspect of the software works.
Has this file been opened successfully in Excel since it was created by bcompiler
??
Writing new files from bcompiler-engine
has not been developed yet; I'm concentrating entirely on reading files at this point. I do recall the difficulty in doing this with bcompiler
, but I can address this much more thoroughly in the new software.
re reason for stopping the script. This happened into relation to the programmes I've been developing for analytical outputs. I was running one and realised that it wasn't going to work properly, so I stop it. I subsequently found that one of the files (a master wb) that was being processed through the programme couldn't be opened - and I was getting the same/similar message to the one we've getting for this file. The programme I was using was actually going into the master, changing selected data and then saving/over writing the existing doc. So it was all outside the bcompiler process, and uses a different process because I believe bcompiler doesn't actually create a document until it has been saved.
I wasn't able to successfully open this file in excel either so it has been corrupted by the look of things.
There have been a number of issues reported where files are corrupted when saving with openpyxl
- some are bugs, some are the result of a user doing weird things. I can't see why opening a file in openpyxl
and not closing it would necessarily cause a corruption - in such a case, you are essentially copying the data from the file into the memory of your program and nothing happens to the file subsequently unless you try to save it. If the program terminates in the meantime, the file is untouched.
The issue could be caused by saving the file in a strange way though - (such as https://bitbucket.org/openpyxl/openpyxl/issues/1256/file-getting-corrupted-during-write where for some reason the save()
function was placed in a loop.
If you or your guys see this happening as a result of the current version of bcompiler
saving the file, please raise an issue (at https://github.com/hammerheadlemon/bcompiler/issues), or if you see the exception being raised by a script you've written, post the script and let me have a look at it. As a point of good practice, you should avoid running scripts on files that you have open too. :+1:
I will ensure that bcompiler-engine
has plenty safeguards in place to try to prevent this from happening.
Unable to open a specific file that has been send by an encryption service. Unable to open in LibreOffice and
load_workbook()
fails withBadZipFile
exception.Untested in Excel but assuming that on the source machine (prior to emailing) it opens fine @banillie?
The following error is received upon trying to open the file in LibreOffice 6.3.0.2:
bcompiler-engine
should include a strict file checking facility to be run prior to any operations by the front-ends that reports errors clearly to the user. An exception from a load operation should never propogate to the user.