1435564 - File blob for MacOS package zero length

Status: UNCONFIRMED

(Core :: DOM: File, defect, P2)

Description

[alex]

Attachment: Test Budget~4607A89C.ynab4.zip

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.119 Safari/537.36

Steps to reproduce:

1. Download attached "zip" file, extract to a directory (so you have the .ynab4 file to test uploading)
1. Go to https://codepen.io/anon/pen/MQyKzd
2. Upload attached .ynab4 file (a mac os "package") on MacOS
3. Open developer console to inspect output


Actual results:

In console, the file has a length of zero. See file blob details below:

lastModified: 1517697023732
lastModifiedDate: Date 2018-02-03T22:30:23.732Z
name: "Test Budget~4607A89C.ynab4"
size: 0
type: ""
webkitRelativePath: ""


Expected results:

On Chrome and Safari on MacOS, the file is properly uploaded with a nonzero file length. Of note, the file is uploaded with a ".zip" appended.

See the Chrome and Safari file blob details below:

lastModified: 1517697023000
name: "Test Budget~4607A89C.ynab4.zip"
size: 16528
type: "application/zip"

Comment 1

[Andrea Marchesini [:baku]]

What happens here is that macOS sees the content of the zip as a single file but, actually, it's a directory.
A directory doesn't have a size (this is not completely true on a posix system...) and it doesn't have a content.
Wondering if zipping the content of a directory is the right approach. Definitely it's not what the spec says to do.

Marion, can you find somebody with a mac to check if macosx returns a particular error code when the user tries to open a file, which is, in reality, a directory? I don't think I can work on this issue, because I don't have the right hardware, at the moment.

Comment 2

[Marion Daly [:mdaly]]

Jan, you have a mac, could you give this a look?

Comment 3

[Marion Daly [:mdaly]]

removing NI and adding to backlog.

Comment 4

[Malik Waqas]

What occurs here is that macOS considers the to be of the compress as a solitary record however, it's a catalog.

A catalog doesn't have a size (this isn't totally evident on a posix system...) and it doesn't have a substance.

Contemplating whether zipping the substance of an index is the correct methodology. Unquestionably it's not what the spec says to do. https://www.konzeptgarden.com/artificial-carpet-grass-supplier-malaysia

Marion, would you be able to discover someone with a macintosh to check if macosx returns a specific mistake code when the client attempts to open a document, which is, in all actuality, a catalog? I don't figure I can chip away at this issue, since I don't have the correct equipment, right now.

Comment 5

[Malik Waqas]

Client Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_3) AppleWebKit/537.36 (KHTML, similar to Gecko) Chrome/64.0.3282.119 Safari/537.36

Steps to replicate:

1. Download connected "compress" record, concentrate to an index (so you have the .ynab4 document to test transferring)

2. Go to https://codepen.io/anon/pen/MQyKzd

3. Transfer connected .ynab4 record (a macintosh os "bundle") on MacOS

4. Open designer comfort to investigate yield

Real outcomes:

In comfort, the record has a length of nothing. See document mass subtleties beneath:

lastModified: 1517697023732

lastModifiedDate: Date 2018-02-03T22:30:23.732Z

name: "Test Budget~4607A89C.ynab4"

size: 0

type: ""

webkitRelativePath: ""

Anticipated outcomes:

On Chrome and Safari on MacOS, the record is appropriately transferred with a nonzero document length. Of note, the document is transferred with a ".zip" added. https://www.konzeptgarden.com/artificial-carpet-grass-supplier-malaysia

See the Chrome and Safari record mass subtleties underneath:

lastModified: 1517697023000

name: "Test Budget~4607A89C.ynab4.zip"

size: 16528

type: "application/zip"