p5.js-web-editor
p5.js-web-editor copied to clipboard
processing
All files in download zips are empty (have 0 bytes)
Details about the bug:
- Web browser and version: various flavors of chromium and firefox (both mobile and desktop).
- Steps to reproduce this:
- Download the project files from the browser.
- This generates a zip archive
- The zip archive contains the correct files containing the correct source code inside, however all files within the zip are marked as a size of 0 bytes
- Some of my archive managers were able to still read the files correctly, despite the apparent 0 B file size. While some of my other archive managers view the files as empty.
I downloaded a project successfully yesterday, then again about 2 hours ago. But right now, all project downloads show files as having 0 Byte size, it doesn't matter if they're my own projects or other projects that have been shared.
Welcome! 👋 Thanks for opening your first issue here! And to ensure the community is able to respond to your issue, be sure to follow the issue template if you haven't already.
![welcome[bot] avatar](https://avatars.githubusercontent.com/in/4141?v=4 "Published by a pub.dev verified publisher"){kind=small}
Can confirm this issue. Tested with chrome on macOS, and chrome, opera , Firefox and edge on win10 all produce zip files containing empty files
Confirmed same issue on MacOS in Safari and Chrome - downloaded zip file contains all zero length files
What does it take to upgrade this to a bug? I'm pretty sure it was not in prior versions of editor. Pretty sure I was downloading ok all of 2021.
What does it take to upgrade this to a bug? I'm pretty sure it was not in prior versions of editor. Pretty sure I was downloading ok all of 2021.
I downloaded a project just fine that same day on July 6, 2022, then two hours later when I downloaded it again the zip archives were messed up, and now three weeks later, export archives are still showing 0 bytes size for all files. So whatever went wrong happened specifically on July 6 -- hopefully that's helpful information to anyone with the ability to make a correction.
Looks like there was quite a lot of activity on July 6: https://github.com/processing/p5.js-web-editor/actions
Dove into the code a little bit this afternoon to see if I might be able to help. I think it might be an issue with the archiver package. I'll keep looking into it and report back.
So I've got a fix for this working locally on my machine that I'm ready to push but, quick question, is it really necessary to include external libs in the zip? The currently deployed version goes and grabs any external scripts referenced in index.html but most of the time these are CDN hosted scripts anyway so, at least to me, it seems pretty superfluous to include them in the download.
Personally I would prefer the external scripts to get pulled from the CDN, but would not want to risk a change in behavior now. Fixing the zero length bug should be the first step and CDN extern script option in a separate pull request.
@dwight9339 thanks for reporting the bug and providing a fix. @jht1900 would you be able to assist in getting #2048 approved and merged? This is a quite important feature of the editor!
@dwight9339 thanks for reporting the bug and providing a fix. @jht1900 would you be able to assist in getting #2048 approved and merged? This is a quite important feature of the editor!
I agree this is important feature! I'll ask around for tips on getting approval of fix.
hi folks, thank you for your attention on this issue. the editor is currently in maintenance mode as we transition to new leadership (see #2010). hope to have an update next month!
I understand the editor is in maintenance mode, but this is a critical bug, which should be fixed in a 'maintenance' state. It's not new functionality, it's core existing infrastructure.
I concur with @pierrep , this is a critical bug.
@kjhollen I see that Leadership Update #2010 is from April - is p5.js updates effectively on hold since then? PS: @kjhollen tiny detail, this issue is marked with "label:bug" whereas most others are "label:type:bug" I wonder if this could affect triage and filters? I myself got lost once until I noticed that.
Considering this feature was broken while the editor was in maintenance mode, it would be a strange policy to say that the same feature must not be unbroken while in maintenance mode.
There have been a few scheduled maintenance items over the last few months that were planned in advance, based on developer availability. While I agree this feature is important, at this time I would only consider a critical issue something like the site being offline entirely, which would need immediate attention.
I have flagged this issue with a high priority label so that it can be fixed when the site is out of maintenance mode, which is happening soon! Last week we announced the new p5.js editor lead and they will be starting September 15. Thank you for reporting this issue and for your patience while we sort out this transition.
are there any workarounds for this issue other than copy pasting all the code and files manually? or do we just need to wait for it to be fixed?
Workarounds:
On Mac os use Safari to download. That works.
On PC you can use peazip to extract the corrupted zip. It throws an wore but still allowed you to extract it properly
On Tue, 30 Aug 2022 at 15:58, volt64bolt @.***> wrote:
are there any workarounds for this issue other than copy pasting all the code and files manually? or do we just need to wait for it to be fixed?
— Reply to this email directly, view it on GitHub https://github.com/processing/p5.js-web-editor/issues/2038#issuecomment-1231708998, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADCDIFLBGOR3OGR27PTH6B3V3YHRHANCNFSM5235KK2Q . You are receiving this because you commented.Message ID: <processing/p5. @.***>
-- Daniel Lacey / Captain Credible Artist, Musician, Maker University Lecturer at AHO, The Oslo School of Architecture and Design +4792464458 / www.captaincredible.com
Proposed workaround does NOT work for me using Safari. Tested on Safari Version 15.6.1 (17613.3.9.1.16), macos 12.5.1
I've been having this problem for months and was finally able to download a project successfully with Safari, as suggested by @CaptainCredible:
- macOS: 12.5.1
- Safari: 15.6.1
Oddly this is the same setup as @jht1493 but the resulting download worked for me - I don't know if this is a Safari thing, but the download wasn't even a .zip, it was just a folder with all the expected files and assets in place and not corrupted.
Note: When unzipping a download from another browser with Mac's built in "Archive Utility", the unzip appeared to be successful, but all the files were still empty/corrupt, so be sure to look carefully.
I was also able to use PeaZip on Windows - as stated, it gives an error but clicking "Keep Files" successfully unzipped them anyway.
Based on @tjvezina comments I am now able to see Safari workaround success with Safari Preference "Open Save files after downloading" enabled.
Would like to add my support for this being a priority issue. Some of my students just submitted homework this way and were stunned to see their initial grades of "zero" for submitting empty files.
Chiming in on this being a priority, students cannot turn in documentation of their work without this feature, it is critical for classroom use.
@stevensrmiller @bmoren I suggest allowing students to submit a URL for their sketches as their homework, for now. I understand other professors and teachers may prefer to have downloaded files for various reasons, but I use the URL only in my classes and it is a reasonable alternative.
Our new dev lead starts tomorrow and this will be a top priority for their first weeks. I expect there will be a little bit of ramp-up time before this issue is fixed. Thanks again to everyone for their patience.
Hi Kate, thanks for the update. I really appreciate it! I'm using links for now, and I'm happy to know its a priority. I like to have the sketches for archiving and documentation. It's especially important for projection/installation works where you need to get rid of the editor bar at the top :)
I've been having this problem for months and was finally able to download a project successfully with Safari, as suggested by @CaptainCredible:
- macOS: 12.5.1
- Safari: 15.6.1
Oddly this is the same setup as @jht1493 but the resulting download worked for me - I don't know if this is a Safari thing, but the download wasn't even a .zip, it was just a folder with all the expected files and assets in place and not corrupted.
Note: When unzipping a download from another browser with Mac's built in "Archive Utility", the unzip appeared to be successful, but all the files were still empty/corrupt, so be sure to look carefully.
I was also able to use PeaZip on Windows - as stated, it gives an error but clicking "Keep Files" successfully unzipped them anyway.
PeaZip worked on Linux for me — after extracting, an error message is shown, but the Keep Files -button successfully extracts all files.
I suggest allowing students to submit a URL for their sketches as their homework, for now.
Unless I'm missing something, this makes impossible any kind of deadline for an assignment, as sketches can be continuously updated, while, for example, an instructor is going over solutions in class
Yes, this is one of the "various reasons" I alluded to in the post you quoted. While it may not work for your teaching style, hopefully one of the other work-arounds suggested in this thread (using Safari if you have a Mac, or other zip tools for Windows and Linux) can work for you while the new project lead is learning the ropes. Please help create a welcoming environment for them. Thanks.
Certainly not my intention to be less than welcoming to @raclim (or anyone else)... especially as this problem has existed since well before she came on board.
I know from experience how difficult it can be to manage open-source projects, but we also have a responsibility to our users when there is a critical bug like this. We should either (imho) address it quickly and/or let people know right away that it is exists -- something like a warning in the interface? -- rather than letting users think it is their own error, which is what new learners especially are likely to believe
In any case, it seems there is already a PR with a fix for this - is it waiting on further review (maybe I can help) ?
@dhowe even updating the site with a banner would have taken resources we didn't really have over the summer, so I've been responding to this thread as a second best option. Earlier I discussed what would constitute a "critical" issue at this time, given our bandwidth over the last few months. Thanks for your offer to help—one of our challenges at the moment is that deployment is non-trivial, otherwise I would have probably tried to patch in a quick fix myself. This will be one of the first issues to be fixed when Rachel is fully onboarded with the tech stack & access to all hosting resources required for deployment. Until then, we appreciate your patience and hope one of the workarounds in this thread can work for your use case.
Welcome to the new dev
Hadn't thought of @dhowe's point, but it's a good one. Will have my students copy-and-paste their submissions while this is pending.