As reported by another user, it seems to be caused by an empty directory in the zip file. Chrome OS seems to be unable to unzip properly when there is an empty directory in the zip file.

From user DennyLfromGA (https://productforums.google.com/forum/?utm_medium=email&utm_source=footer#!msg/chromebook-central/vvQ8KqFBimQ/oLSl9oknCgAJ)

"It might be the way the vendor is packaging the zip file, it seems there is an empty directory stored as the first item.

Here is a listing of the zip file contents -

unzip -l Nendoroid_gilgamesh.zip 
 
Archive:  Nendoroid_gilgamesh.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
        0  2016-09-12 23:16   /
   163637  2014-04-09 18:51   04.jpg
   152306  2014-04-09 18:51   05.jpg
   193192  2014-04-09 18:51   01.jpg
   200062  2014-04-09 18:51   02.jpg
   162445  2014-04-09 18:51   03.jpg
---------                     -------
   871642                     6 files

I did successfully unzip it from a command line, but it displayed the following error -

unzip ../Nendoroid_gilgamesh.zip
  
Archive:  ../Nendoroid_gilgamesh.zip
warning:  stripped absolute path spec from /
mapname:  conversion of  failed
  inflating: 04.jpg                  
  inflating: 05.jpg                  
  inflating: 01.jpg                  
  inflating: 02.jpg                  
  inflating: 03.jpg

So I think the way it's zipped up on the Dropbox site might be a problem; only zip the files, not the directory."

Great job at identifying the anomaly. Since this file IS currently handled by Drive and other platforms, can the ChromeOS unzipped be fixed for consistency?

To add, it seems Dropbox adds this null directory when creating zip files for some reason. If you goto this link:

https://www.dropbox.com/sh/lk13dzbdcw6ong5/AABmP3OEbXh9laVBSo45J2X2a?dl=0

It will allow you to 'Download as zip' (see attached screenshot).
When you do, it adds the empty directory every time.
But, as Jim.Dan... mentioned in the Chromebook Central topic linked in #c1 -
"If, however, I save the files to MY Dropbox storage, and then select them and download as a zip, I see the files just fine!"

I don't know of a way to change this behavior on Dropbox (without signing in) so it's a very real problem when trying to use these zip files in Chrome OS.

Deleted: Screenshot 2016-09-15 at 1.10.16 PM.png 309 KB

	Screenshot 2016-09-15 at 1.10.16 PM.png 309 KB View Download

(Bulk Edit) Adding the new conops Chrome OS hotlist to all open issues with the "#CBC-RS/TC-watchlist" tag, our former tracking tag.

Verified by creating a trivial test case:
% python
>>> f = zipfile.ZipFile('test.zip', 'w')
>>> f.writestr('/', '')
>>> f.writestr('hello.txt', 'Hello, World!')
>>> f.close()

% unzip -lv test.zip
Archive:  <redacted>/test.zip
 Length   Method    Size  Cmpr    Date    Time   CRC-32   Name
--------  ------  ------- ---- ---------- ----- --------  ----
       0  Stored        0   0% 10-10-2018 13:24 00000000  /
      13  Stored       13   0% 10-10-2018 13:24 ec4ac3d0  hello.txt
--------          -------  ---                            -------
      13               13   0%                            2 files

Both unzip and Google Drive's preview both handle this file. The current zip_archiver handler doesn't handle this, but the original AVFS mounter does.

A little more research suggests the zip file is actually malformed. From the spec:

4.4.17 file name: (Variable)

       4.4.17.1 The name of the file, with optional relative path.
       The path stored MUST not contain a drive or
       device letter, or a leading slash.  All slashes
       MUST be forward slashes '/' as opposed to
       backwards slashes '\' for compatibility with Amiga
       and UNIX file systems etc.  If input came from standard
       input, there is no file name field.

I guess absolute paths are invalid. But since these are seen in the wild, we should still do something reasonable. I suspect other archivers are treating all paths as relative, so I think it makes sense to follow that behaviour. There are cases that can't be handled by that, but since the archives are invalid, we can't handle every case.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/1f4d773539f68280819ea8eea16e129f0f17dec1

commit 1f4d773539f68280819ea8eea16e129f0f17dec1
Author: Anand K. Mistry <amistry@chromium.org>
Date: Fri Oct 26 06:32:40 2018

Treat absolute paths in zip files as relative

Absolute paths in zip files are invalid, as per the APPNOTE:

4.4.17 file name: (Variable)
       4.4.17.1 The name of the file, with optional relative path.
       The path stored MUST not contain a drive or
       device letter, or a leading slash.  All slashes
       MUST be forward slashes '/' as opposed to
       backwards slashes '\' for compatibility with Amiga
       and UNIX file systems etc.  If input came from standard
       input, there is no file name field.

However, zip files in the wild and ones generated by some services do
have them, so they should be handled in a reasonable manner, as other
platform (including Google Drive) do. Stripping the leading slash and
treating the path as relative seems reasonable. This won't work if there
are two files with the same path, but one being relative and the other
absolute. But in this case, the archive was already invalid, so any
attempt to handle it is best effort.

BUG= 646850 

Change-Id: I7681e888bb78d7f4f53c7bd3a5ab318bffb8c527
Reviewed-on: https://chromium-review.googlesource.com/c/1301094
Reviewed-by: Tatsuhisa Yamaguchi <yamaguchi@chromium.org>
Commit-Queue: Anand Mistry <amistry@chromium.org>
Cr-Commit-Position: refs/heads/master@{#603005}
[modify] https://crrev.com/1f4d773539f68280819ea8eea16e129f0f17dec1/chrome/browser/chromeos/file_manager/file_manager_browsertest.cc
[modify] https://crrev.com/1f4d773539f68280819ea8eea16e129f0f17dec1/chrome/browser/resources/chromeos/zip_archiver/cpp/volume.cc
[add] https://crrev.com/1f4d773539f68280819ea8eea16e129f0f17dec1/chrome/test/data/chromeos/file_manager/absolute_paths.zip
[modify] https://crrev.com/1f4d773539f68280819ea8eea16e129f0f17dec1/ui/file_manager/integration_tests/file_manager/zip_files.js
[modify] https://crrev.com/1f4d773539f68280819ea8eea16e129f0f17dec1/ui/file_manager/integration_tests/test_util.js

And appears to be targeted for version 72.0.3593.0