[WebPositive] sometimes downloads files as "-0"

[diver]

hrev48517.

under some circumstances WebPositive saves downloaded file as "-0" as filename. Downloading the same file again most of the time work as expected. Will try to find a reproducible url.

[haiqu]

Verified here as well. A second file will become '-1', etc. I'm also getting a lot of broken downloads, which is costly when the file approaches 1Gb (such as Raspbian images).

Seems to be worse when using https, and may have something to do with mimetype not being properly recognised.

[pulkomandy]

Please don't mix different problems. This one is about not having the right filename only. This is unrelated to download failures and MIME type, so if you also have problems with that, please open separate tickets.

Also, please provide links where it happened to you (even if not reproductible, it could still give a hint).

[vidrep]

I have also seen this problem intermittently for several months. Last time only a couple of days ago while trying to download an anyboot image from Haiku.

[vidrep]

I have it happening now while downloading the latest x86_gcc2 hybrid anyboot image (see screenshot1).

[tqh]

Similar thing also happens while building Haiku under Linux. Sometimes downloads creates a -.0.

[ttcoder]

FWIW, I saw the "decrementing integer" aspect from comment:1 here, I tried four times to download an attachement from a ticket (with Web+). The fourth attempt succeeded, but the first three were named

-0
-1
-2

Interestingly, the META:url attribute is empty for those:

~/Desktop> catattr META:url 0 1 2
0 : string :
1 : string : 
2 : string : 

[pulkomandy]

It's not decrementing, but incrementing and prefixed with a dash :)

What happens is:

• WebKit somehow fails to provide a file name for the download
• The path ends up as download/folder/, which "already exists"
• The code then adds "-number" at the end of the name, until it finds something that doesn't exist.

In normal cases this would lead to "download/folder/file.txt", "download/folder/file.txt-0", "download/folder/file.txt-1", etc. With an empty file name, only the -0 is left, and we get "download/folder/-0", etc.

The name is extracted from HTTP Content-Disposition at ​https://github.com/haiku/webkit/blob/rebased/Source/WebCore/platform/network/haiku/BUrlProtocolHandler.cpp#L477 . If that fails, the last part of the URL should be used.

[axeld]

Clobbering the extension sounds like a bug in itself.

[pulkomandy]

Possibly fixed in hrev50917. Can you still reproduce?

[vidrep]

Generally I'm most likely to encounter this bug while attempting to download Haiku nightly anyboot images (which I do every couple of days). Please keep the ticket open, and I'll report back in a week or two should I see the bug or not.

[humdinger]

I think we can close this one. I had those 0-files myself quite often in the past. Not once since the latest webkit update. Vidrep?

[vidrep]

I really haven't done much downloading since I made the comment. That being said, I have not encountered the issue when I have downloaded. We can always reopen, if need be.

[vidrep]

hrev51295 x86_gcc2h

Downloading the current nightly anyboot image as filename -0 (see Download.png)

Copy/Paste the URL into wget downloads the zip with correct name

[diver]

It looks like I can reliably reproduce it using vlc nightlies: ​http://nightlies.videolan.org/build/source/vlc-3.0.0-20170810-0240-git.tar.xz

[pulkomandy]

Should be fixed (again) in HaikuWebKit 1.6.2. Can you still reproduce?

[pulkomandy]

(In #13085) This is a different manifestation of #11632.

When a directory exists, we create files named -0, -1, ... inside it. When the download directory does not exist, we create a file with its name, then name-1, name-2, etc.

By the way, all these issues (also the other ones with about:blank which you reopened, and some more), are not really related to the haikuwebkit version. They are all tied to a race condition (two threads getting out of sync) somewhere in the HTTP code, which triggers more or less easily depending on your machine, network speed, and the webkit code which just happens to have different timings in each version. Hence the issue will come and disappear again until we can catch and fix the root problem.

[pulkomandy]

Is this still reproducible with a recent nightly and haikuwebkit 1.6.3?

[vidrep]

Seems to be working for me using HaikuWebKit 1.6.3 on 64 bit. Since the issue is somewhat intermittent, I'd like to hold off on closing for a couple of weeks.

[waddlesplash]

Well, that was a long few weeks... so this must be fixed :)

[nielx]

Assign tickets with status=closed and resolution=fixed within the R1/beta2 development window to the R1/beta2 Milestone