Issue logs in this link:
https://pantheon.corp.google.com/storage/browser/chromiumos-test-logs/bugfiles/cr/787532/

Crash information:
Crash Report ID b5dcb17ec1706c8d (Local Crash ID: Chrome)
Crash Report ID d451180d55edd61e (Local Crash ID: Chrome)
Crash Report ID a6058181ac6fb018 (Local Crash ID: Chrome)

yamaguchi@ - Can you take a look at this behavior? Unzipping files should no longer trigger this notification in most cases now that we've made the zip improvements updates.

I saw some of the issues can happen without enabling Zip Archiver. (i.e. with the ZIP unpacker extension)

My guess is that "zip file inside a zip file" makes the read operations even slower than usual, which describes all the reported issues. IIUC, the file can be unmounted after waiting for a long enough time.

> At step 2: Observed Abort notification frequently popping up and was auto-dismissing.
If it dismisses and finishes all operations after waiting for a while, this would be WAI.
Frequent popup can be caused by doing several operations inside and each of those taking a long time.
We may consider more friendly control of the frequency to give this type of notification as a UI improvement.

> At step 4: Saw an error message dialog.
This is caused by some app (most likely Files app. generating thumbnails) keep accessing the contents of the archive. This should stop showing up after all the operations are finished after enough time.
I think we should change the message per Issue 785091 to make it less confusing. (zip is not a removable device.)

> At step 5: Files app window was in white background and continued to see abort notification. After sometime, Files window got loaded with the content and was able to unmount the archive files. Abort notification pop up stopped after I unmounted the archives.  
I think the first issue here is that Files app. starts slow. Filed Issue 788338 as we can think of this as a separate issue.
However I'd need more investigation to see why "taking longer time" notification popped up even after loading is finished.

> 5. Sign out and sign in back. Open Files app.
I think this is resolved now by not mounting the heavy zip file after sign out and in. ( Issue 789073 )

> However I'd need more investigation to see why "taking longer time" notification popped up even after loading is finished.
This comment points to the report line in #0:
> At step 5: Files app window was in white background and continued to see abort notification. After sometime, Files window got loaded with the content and was able to unmount the archive files. Abort notification pop up stopped after I unmounted the archives.  
I guess this is because user could unmount the zip only after all the loading operations are finished. (let me know if this is not true.)

To summarize,
Step 2 (frequent notification): Filed Issue 791919 as a UI feature improvement.
Step 4 (wrong error msg.): Resolved by Issue 785091.
Step 5 (startup): Resolved by Issue 788338.

Issue 791919 is the remaining issue.
I think this was marked as M-64 Pri1 due to regressions in steps 4 and 5, but those has been resolved. So marking this as fixed for verification.
Feel free to reopen if Issue 791919 is still considered needed for M-64.

I think this issue is still not fixed yet. I ran this scenario on M65 build (10254.0.0/ 65.0.3299.0) and here are the issues I found:
'Archive.zip' is the first zip file.
'Archive(1).zip' is the second zip file.

1. Tried to open 'Archive(1).zip' file from 'Archive.zip'. The first zip file 'Archive.zip' got mounted.
2. When tried to mount 'Archive(1).zip' file, observed a notification as 'Please wait, the archive is being scanned...'. After sometime, another notification popped up saying 'The archive is already mounted.'
3. But 'Archive(1).zip' was still not mounted. Waited for a long time, second zip file 'Archive(1).zip' never got mounted.
4. Now when tried to unmount the first zip file, observed 'Cannot unmount volume' error message. Waited for a long time, I'm unable to unmount the first zip file. Even after closing and re-opening Files app/ refreshing the archive volume I'm unable to unmount the first file.
5. Also, frequent abort notification was popping up. Clicking on ABORT button had no impact on the unzipping process as well as the notification pop up.
6. After sign out and sign in back, zip archive was unmounted by its own.

Please refer the attachments. 

Deleted: Screenshot 2017-12-27 at 5.14.20 PM.png 441 KB

	Screenshot 2017-12-27 at 5.14.20 PM.png 441 KB View Download

Deleted: Screenshot 2017-12-27 at 5.14.35 PM.png 459 KB

	Screenshot 2017-12-27 at 5.14.35 PM.png 459 KB View Download

> After sometime, another notification popped up saying 'The archive is already mounted.'
Did it happen when opening each archive only once and waiting, or when opening it again while waiting?

(If latter, it's likely  Issue 789126 , which is not fixed yet with currently delivered version.)

Hi yamaguchi, it is the latter case i.e. when tried opening the file again while waiting, that I observed this notification ('The archive is already mounted.').

So, will this be fixed as part of  Issue 789126  ? Because I can see this issue is already marked as wont fix. 

I think this bug needs triage.

The issue noted in Comment 7 should have been fixed by 65.0.3301.0 or later.
(It is because of the Zip Archiver for unpacking / Issue 690217.)
So now this only affects M64 release branch. We may choose to fix it especially for M64, but it requires some significant work for  Issue 789126 .

Opening archive inside archive is considered as a separate issue, because it makes the operation actually slow even when not falling into erroneous state. Filed Issue 803100. (it can also happen on M65+.)

Hi yamagucchi, the issue mentioned in #7 is sometimes seen on M65 build (10315.0.0, 65.0.3322.0) kevin, but not frequently. 
I had 3 nested zip archives. Opening 3rd zip file was taking more time than expected as described in Issue 803100. At this point, observed 'Archive is being scanned..' notification. 
a. When tried re-opening this file again while in wait mode, I observed ABORT notification or sometimes this zip file (i.e. the 3rd zip file) doesn't mount at all.
b. I also observed 'Unable to unmount...' error message when tried to unmount the previously mounted archives while in wait mode.

Issues in points a. and b. doesn't happen always.

> I had 3 nested zip archives. Opening 3rd zip file was taking more time than expected as described in Issue 803100. At this point, observed 'Archive is being scanned..' notification. 
> a. When tried re-opening this file again while in wait mode, I observed ABORT notification or sometimes this zip file (i.e. the 3rd zip file) doesn't mount at all.
I think this is Issue 803100. It affects both the old and new Zip extensions. So it will still be seen on M65. It may look practically "doesn't mount at all" as it takes too long.

> b. I also observed 'Unable to unmount...' error message when tried to unmount the previously mounted archives while in wait mode.

Since it is still processing the archive for mounting, that volume is not unmounted for safety. ( Issue 789562 )

I don't think that issues in #11 are a blocker for Issue 690217 because thesea are not a regression and happens regardless of if we enable the Zip Archiver extension (#zip-archiver-unpacker).

As a workaround, user can sign out and sign in again. (because  Issue 789073  was done)

Removing this issue from blocker list of Issue 690217, because Issue 690217 is an update that will resolve a part of this issue.
- When user attempts to open a zip file again while mounting (opening the archive to get file list) is in progress, it stopped opening the archive and it also disabled opening other zip files. It also gave wrong message "already mounted" for the first file. After the update, it will not happen.

Feel free to add back if this is still considered a blocker.

<files-triage>

Moving to M-67, please update if incorrect.

This should be fixed with the launch of zip archiver; please try repro with zip archiver enabled.

I don't see this issue except for the case of Issue 803100 (nested zip file).
Closing as we have fixed various other issues.
Feel free to reopen if this still happens without a nested zip file, on the latest revision.

I'm now seeing this problem now. Verified on M67 eve (10575.16.0, 67.0.3396.19).