Opened 9 years ago

Closed 5 years ago

Last modified 4 years ago

#11632 closed bug (fixed)

[WebPositive] sometimes downloads files as "-0"

Reported by: diver Owned by: pulkomandy
Priority: normal Milestone: R1/beta2
Component: Applications/WebPositive Version: R1/Development
Keywords: Cc:
Blocked By: Blocking: #13085
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 9 years ago.
Download.png (183.4 KB ) - added by vidrep 7 years ago.

Download all attachments as: .zip

Change History (26)

comment:1 by haiqu, 9 years ago

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 by pulkomandy, 9 years ago

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 9 years ago by pulkomandy (previous) (diff)

comment:3 by vidrep, 9 years ago

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 by vidrep, 9 years ago

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

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

by vidrep, 9 years ago

Attachment: screenshot1.png added

comment:5 by tqh, 9 years ago

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

comment:6 by ttcoder, 9 years ago

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 by pulkomandy, 9 years ago

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 by axeld, 9 years ago

Clobbering the extension sounds like a bug in itself.

comment:9 by pulkomandy, 7 years ago

Possibly fixed in hrev50917. Can you still reproduce?

comment:10 by vidrep, 7 years ago

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 by humdinger, 7 years ago

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 by vidrep, 7 years ago

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 by humdinger, 7 years ago

Resolution: fixed
Status: newclosed

comment:14 by vidrep, 7 years ago

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

Version 0, edited 7 years ago by vidrep (next)

comment:15 by vidrep, 7 years ago

Resolution: fixed
Status: closedreopened

by vidrep, 7 years ago

Attachment: Download.png added

comment:16 by vidrep, 7 years ago

patch: 01

comment:17 by pulkomandy, 7 years ago

patch: 10

comment:18 by diver, 7 years ago

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 by pulkomandy, 7 years ago

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

comment:20 by pulkomandy, 7 years ago

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 by pulkomandy, 6 years ago

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

comment:22 by vidrep, 6 years ago

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 by waddlesplash, 5 years ago

Resolution: fixed
Status: reopenedclosed

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

comment:24 by nielx, 4 years ago

Milestone: R1R1/beta2

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

Note: See TracTickets for help on using tickets.