Opened 4 years ago

Closed 4 months ago

#11632 closed bug (fixed)

[WebPositive] sometimes downloads files as "-0"

Reported by: diver Owned by: pulkomandy
Priority: normal Milestone: R1
Component: Applications/WebPositive Version: R1/Development
Keywords: Cc:
Blocked By: Blocking: #13085
Has a Patch: no Platform: All

Description

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.

Attachments (2)

screenshot1.png (90.3 KB) - added by vidrep 4 years ago.
Download.png (183.4 KB) - added by vidrep 22 months ago.

Download all attachments as: .zip

Change History (25)

comment:1 Changed 4 years ago by 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.

comment:2 Changed 4 years ago by 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).

Last edited 4 years ago by pulkomandy (previous) (diff)

comment:3 Changed 4 years ago by 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.

comment:4 Changed 4 years ago by vidrep

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

Last edited 4 years ago by vidrep (previous) (diff)

Changed 4 years ago by vidrep

Attachment: screenshot1.png added

comment:5 Changed 4 years ago by tqh

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

comment:6 Changed 4 years ago by 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 : 

comment:7 Changed 4 years ago by 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.

comment:8 Changed 4 years ago by axeld

Clobbering the extension sounds like a bug in itself.

comment:9 Changed 2 years ago by pulkomandy

Possibly fixed in hrev50917. Can you still reproduce?

comment:10 Changed 2 years ago by 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.

comment:11 Changed 2 years ago by 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?

comment:12 Changed 2 years ago by 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.

comment:13 Changed 2 years ago by humdinger

Resolution: fixed
Status: newclosed

comment:14 Changed 22 months ago by 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

Last edited 22 months ago by vidrep (previous) (diff)

comment:15 Changed 22 months ago by vidrep

Resolution: fixed
Status: closedreopened

Changed 22 months ago by vidrep

Attachment: Download.png added

comment:16 Changed 22 months ago by vidrep

Has a Patch: set

comment:17 Changed 22 months ago by pulkomandy

Has a Patch: unset

comment:18 Changed 22 months ago by 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

comment:19 Changed 21 months ago by pulkomandy

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

comment:20 Changed 21 months ago by pulkomandy

Blocking: 13085 added

(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.

comment:21 Changed 18 months ago by pulkomandy

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

comment:22 Changed 18 months ago by 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.

comment:23 Changed 4 months ago by waddlesplash

Resolution: fixed
Status: reopenedclosed

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

Note: See TracTickets for help on using tickets.