Downloaded zip files not freed for approx 30 secs

NEW
Unassigned

Status

()

Toolkit
Downloads API
10 years ago
9 years ago

People

(Reporter: aja+bugzilla, Unassigned)

Tracking

Trunk
x86
Windows XP
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

10 years ago
Downloaded zip files not freed for approx 30 secs unless DM window closed.
Exe files seem to get freed as soon as the "all downloads completed" popup notification is displayed, as expected.
XP/SP2, Windows Defender, and AVG Free.
Option to close DM window when all files complete is not selected.

Haven't nailed down regression window yet, but IIRC this seems to have begun around same time as landing of bug 418960 "Download scanner threads should be lower priority".
(Reporter)

Comment 1

10 years ago
Removing "unless DM window closed" from title, based on further testing.
Summary: Downloaded zip files not freed for approx 30 secs unless DM window closed → Downloaded zip files not freed for approx 30 secs
I see this too, with AVG Free on XP SP2 with Windows Defender enabled; Rob, do you have cycles to look at this?  Is it expected scanning would take this long, since we lowered the thread's priority?
What do you mean by freed? Is it that there is a lock on the file or they are still in the scanning state for 30 seconds or something else? 30 seconds corresponds exactly to the download scanner watchdog timeout, so it's possible that this has nothing to do with the thread priority bug (which landed shortly after the watchdog patch).
(Reporter)

Comment 4

10 years ago
Unable to drag/drop the zip file from the download directory to another, win says it's unable due to it being held by another process.  This is after the (first?) scan has run, and after the "all downloads complete" message popup. 
Ok, so someone is holding a lock on the file. Since the download is in the finished state it's probably not any download manager code, so I suspect the virus scanner is at work. If you download the same file in beta 3 or any build before the watchdog patch landed (bug 409815), does it complete the scan in less than 30 seconds?
(Reporter)

Comment 6

10 years ago
Just tested using 3.0b3: 
No discernible lock after the "all downloads complete" message popup.
Was able to drag/drop zip to another directory immediately.
Right, that's expected. What I need to know is if the download was in the scanning state for more than 30 seconds in b3. In b3, if the "all downloads complete" popup shows up, the virus scanner is done. After the watchdog checkin, this is no longer true.
(Reporter)

Comment 8

10 years ago
Without having looked at the code...
Is it possible AVG Free scan via IOfficeAntiVirus is prematurely triggering the "all downloads complete" message popup, and then Windows Defender scan is being invoked via IAttachmentExecute (and  keeping the lock until it's done).
No. Either IAttachmentExecute is run or we run all enumerated IOfficeAntiVirus scanners.
(Reporter)

Comment 10

10 years ago
(In reply to comment #7)
> Right, that's expected. What I need to know is if the download was in the
> scanning state for more than 30 seconds in b3.

In both b3 and recent b4pre, I'm getting a fairly long scanning state; long enough to indicate a real (AVG?) scan is being performed.  Not a real quick scanning state like when call is made but no scan is really done.

you aren't answering the question - does it take longer than thirty seconds?
(Reporter)

Comment 12

10 years ago
Just timed a b4pre scanning state, and it appeared to be right at 30 secs.
 
(Reporter)

Comment 13

10 years ago
Just timed a couple manual AVG scans of the same zip...and those are taking 40+ secs. 
I need the scan time for b3. Anything with the watchdog patch (b4pre) will take
no longer than 30 seconds to show that it's done being scanned (the scan may
very well take longer than 30 seconds...that's what we're trying to figure
out).
(Reporter)

Comment 15

10 years ago
b3 scan times are 40+ secs
(Assignee)

Updated

10 years ago
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.