ZIP unpacker: shows inconsistent errors and results on every 2 attempts to open mounted ZIP |
|||||||||
Issue descriptionChrome Version: 64.0.3280.0 ZIP unpacker version: 0.76.2 What steps will reproduce the problem? (1) Open a ZIP file in the Files app. (2) Move back to the first folder and open the ZIP file again. (3) Open the ZIP file once again. What is the expected result? (2) The Files app. opens the mounted volume of the ZIP file. (3) The Files app. opens the mounted volume of the ZIP file. What happens instead? (2) Current directory unchanged. System notification pops up. "The archive is already mounted." The console of the ZIP unpacker shows error log "ALREADY EXISTS, COME ON!" and "EXISTS". (3) Current directory moves to the ZIP volume. However, the system notification message is changed to "The archive format is not supported, or the file is broken." #2 might have been WAI, but we've decided that it should move to the mounted volume in the same window. Since this doesn't return ALREADY_MOUNTED result to the Files app., this affects that change (Issue 647985). This also happens with a valid ZIP file, and it can still see the content of the archive. Therefore the message in #3 is considered wrong.
,
Nov 28 2017
User can see the "the archive is already mounted" at the first time, but messages after that will not be visible unless opening the notification center ("1" icon at right-bottom corner of the desktop).
By this reason, this looks as if it is silently failing without showing any message at step (2), if user tries this several times.
,
Nov 30 2017
,
Dec 5 2017
I've confirmed that this happens with 0.76.2, but already fixed with 0.77.
,
Dec 28 2017
Did we apply any patch to 0.76.3 related to this issue? (or have we ever found a cause or fixing commit?)
,
Jan 9 2018
Reopening because this is a blocker of Issue 647985.
,
Jan 9 2018
We need to set #zip-archiver-unpacker flag Disabled to reproduce this. (Alternatively, pass --disable-zip-archiver-unpacker commandline option.)
,
Jan 9 2018
I've found another scenario probably caused by the same bug. (1) prepare a big zip file (about 100MB+) in Drive (2) open chrome://drive-internals and click [Clear local data] in Local Metadata section (3) Open the zip file. (4) Open the zip file again before it finishes syncing. (5) Wait the file is synced, and see if the zip is mounted. EXPECTED: The zip is mounted after sync(download) finished. ACTUAL: Not mounted even after sync finished. Opening the zip file again will not mount the file, giving either error message in #0. Signing in again will make it recover from this state. We can also see the progress at the "In-flight Operations" section in chrome://drive-internals.
,
Feb 22 2018
,
Feb 28 2018
,
Feb 28 2018
,
Mar 12 2018
I cannot reproduce original problem from #c1 in 67.0.3365.0 When I click on Downloads/test.zip, it opens the mounted zip and shows me contents. When I go back to Downloads, and click Downloads/test.zip again it takes me back to the already-mounted zip file and shows me contents. I have not attempted to recreate the scenario described in #c8. It is possible that it is still an issue.
,
Mar 12 2018
Just in case, we'll need to turn on the flag #disable-zip-archiver-unpacker because this is an issue with the older extension. This issue will become less important once we release Zip Archiver by 690217.
,
Mar 15 2018
Can't reproduce with or without #disable-new-zip-unpacker Google Chrome 65.0.3325.148 (Official Build) beta (64-bit) Platform 10323.52.0 (Official Build) beta-channel samus |
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 Deleted