MozillaZine

[Ext] Preserve Download Modification Timestamp 2013.05.11.19

Announce and Discuss the Latest Theme and Extension Releases.
zzzzzzzzzz
 
Posts: 133
Joined: October 4th, 2010, 6:04 pm

Post Posted August 25th, 2011, 10:02 am

I have redownloaded the "ofw08charity.exe" file after setting Preserve Download Modification Timestamp 2011.03.21.22 log verbosity to "3 - Debug".

I had cleared the firefox log file using the "Clear" button on the GUI log window. I did not know where Firefox 6.0 keeps its log file (if one is kept), so I took an image of the log window.

The image of the log report:

Image

zzzzzzzzzz
 
Posts: 133
Joined: October 4th, 2010, 6:04 pm

Post Posted September 13th, 2011, 3:56 pm

I have determined why I was getting an exception in the Error logs and also the server timestamp of files not being set to the downloaded files.

I have reinstalled and tested older Firefox versions (such as 3.6 series) and have also noticed the problem manifesting.

The problem seems to have manifested when Eset, the antivirus provider, I and many others use, updated its NOD32 2.70.39 product silently (there should not have been any updates at all (according to Eset) for this older product).

Eset seems to be crippling at least one of their older products and doing so prior to when they officially should no longer support the product. After updating what should have only (apparently the software allows and allowed its modification remotely without user authorization) been virus definitions, the software becomes adware (advertising their newer products) with a process being retained in memory continuously and with every start-up of Windows, unless terminated explicitly by the user (such as with Task Manager). The software now fails to scan properly (email clients generate errors where before they did not and realtime scanning may result in unusual behavior (such as exception in Preserve Download Modification Timestamp 2011.03.21.22 when downloading a file)) The software no longer provides updated virus definitions newer than August 12, 2011 (Eset should have provided updated definitions through the end of January 2012).

Eset is no longer a good quality antivirus vendor like it once was; it has much changed for the worse.

Setting browser.download.manager.scanWhenDone to false did not workaround the problem.

A workaround for the problem might be possible in a Firefox update should Mozilla provide one.

zzzzzzzzzz
 
Posts: 133
Joined: October 4th, 2010, 6:04 pm

Post Posted February 12th, 2012, 5:13 pm

After further examination, the failure to append proper server date and time information to a downloaded file when NOD32 3.70.39 is used applies to more than just the trial version of the NOD32 2.70.39 software product. The problem also manifests with any other version of NOD32 2.7.0.39. The problem manifest-ability might extend to other versions of NOD32 or other software products.

zzzzzzzzzz
 
Posts: 133
Joined: October 4th, 2010, 6:04 pm

Post Posted February 23rd, 2012, 11:29 am

Preserve Download Modification Timestamp 2011.03.21.22 may not be working correctly on the latest version of the Firefox-based browser, Pale Moon 3.6 (which is 3.6.30) or previous versions of Pale Moon of the same version series.

Pale Moon is a Firefox-based web browser that is re-branded and compiled for the Windows platform only. Other than the branding, the user interface design should be the same as Firefox and Firefox add-ons should also be compatible. There are some differences in the default configuration and settings between Firefox and Pale Moon.

The problem is: The appending of the file timestamp from server occurs on Firefox 3.6.26, but not on Pale Moon 3.6.30 when the Preserve Download Modification Timestamp extension is installed and the download is allowed to complete before specifying the directory and name for the save of the file.

The problem is documented in the following thread:
http://forum.palemoon.org/viewtopic.php ... 485&p=2185

The author of the Pale Moon browser states that the problem is something to be looked at by the add-on author.

@Bluefang: Please examine the issue and fix it if you can. EDIT: Also, the author of Pale Moon is someone you would have had communication with in the past; he had developed the Pale Moon Status bar extension derived from the Status-4-Evar extension.

Bluefang

User avatar
 
Posts: 7857
Joined: August 10th, 2005, 2:55 pm
Location: Vermont

Post Posted February 25th, 2012, 4:13 pm

The line where it is failing is a call into Mozilla code (nsIFile.lastModifiedTime). This works on all officially supported versions (Firefox 3.5+ and SeaMonkey 2.0+).

If it is failing for you, then it was something changed on PaleMoon or something on your system interfering with it (i.e. preventing it from modifying the file system). I have no control of what happens after this point, so it's not the extension's fault.
There have always been ghosts in the machine... random segments of code that have grouped together to form unexpected protocols. Unanticipated, these free radicals engender questions of free will, creativity, and even the nature of what we might call the soul...

zzzzzzzzzz
 
Posts: 133
Joined: October 4th, 2010, 6:04 pm

Post Posted February 27th, 2012, 9:32 pm

Bluefang wrote:The line where it is failing is a call into Mozilla code (nsIFile.lastModifiedTime). This works on all officially supported versions (Firefox 3.5+ and SeaMonkey 2.0+).

If it is failing for you, then it was something changed on PaleMoon or something on your system interfering with it (i.e. preventing it from modifying the file system). I have no control of what happens after this point, so it's not the extension's fault.
Thanks, Bluefang.

I have been able to rule out other (than the operating system) security software by testing without security software.

I shall communicate this information provided to the Pale Moon browser developer.

zzzzzzzzzz
 
Posts: 133
Joined: October 4th, 2010, 6:04 pm

Post Posted February 29th, 2012, 5:56 pm

zzzzzzzzzz wrote:
Bluefang wrote:The line where it is failing is a call into Mozilla code (nsIFile.lastModifiedTime). This works on all officially supported versions (Firefox 3.5+ and SeaMonkey 2.0+).

If it is failing for you, then it was something changed on PaleMoon or something on your system interfering with it (i.e. preventing it from modifying the file system). I have no control of what happens after this point, so it's not the extension's fault.
...
I shall communicate this information provided to the Pale Moon browser developer.
The information has been communicated to the Pale Moon browser developer and is documented at: http://forum.palemoon.org/viewtopic.php?f=16&t=485 .The responses are documented at http://forum.palemoon.org/viewtopic.php?f=16&t=485 and http://forum.palemoon.org/viewtopic.php ... 5&start=10 .

The responses from the Pale Moon browser developer are:
Moonchild from http://forum.palemoon.org/viewtopic.php?f=16&t=485 wrote:There is nothing about nsIFile that I can change - it is 100% the same as official Mozilla Firefox builds.

If this is a result of timing issues, which it seems to be considering it works if the file already exists, then I'm afraid the add-on simply won't work on the Pale Moon equivalent because it does things too fast. It would need a purposeful delay in the add-on before trying to set the timestamp so the file system and OS back-end would be done with their administration/configuration of the file before trying to change file attributes.
Moonchild from http://forum.palemoon.org/viewtopic.php ... 5&start=10 wrote:
Do you use code from different version of the Firefox source?

No...The only adopted code from other versions are individual bugfixes for isolated problems.

Although you do make me think about one major difference here: Pale Moon does not include the code for the "download scanner". If the add-on uses the interface with Firefox that is normally used to trigger an anti-virus scan after download to set the date/time (which would be a little odd, but possible), then the add-on will simply never work. Only Sparky can answer that question, though.


@Bluefang: What is your opinion as to what is happening and what do you think can be done to resolve the problem?

Bluefang

User avatar
 
Posts: 7857
Joined: August 10th, 2005, 2:55 pm
Location: Vermont

Post Posted February 29th, 2012, 6:48 pm

That's a load of crock. I think the developer is drinking a bit too much of his own Kool-Aid. PaleMoon is negligibly faster than vanilla Firefox. Even if it was significantly faster, that would suggest that Firefox would have different behavior depending on how fast your computer was, which is not the case. Also:

* The "download finished" event triggers after Firefox is finished messing around with the file.
* The extension checks to make sure the file exists before attempting to modify it.

The extension does not use the DL scanning API. However, if not careful, its removal could potentially change the behavior and/or order of download status events, which would affect the extension.

Have you verified that PDMTS still works on your computer with the vanilla version of Firefox?
There have always been ghosts in the machine... random segments of code that have grouped together to form unexpected protocols. Unanticipated, these free radicals engender questions of free will, creativity, and even the nature of what we might call the soul...

zzzzzzzzzz
 
Posts: 133
Joined: October 4th, 2010, 6:04 pm

Post Posted February 29th, 2012, 8:50 pm

Bluefang wrote:Have you verified that PDMTS still works on your computer with the vanilla version of Firefox?
I have. I have both Pale Moon and Firefox installed. PDMTS works on vanilla Firefox as expected, the NOD32 antivirus system issue expressed earlier in this thread notwithstanding.

Bluefang wrote:Also:

* The "download finished" event triggers after Firefox is finished messing around with the file.
* The extension checks to make sure the file exists before attempting to modify it.
I have noticed that download management software applications (like Orbit Downloader V2.8.20) append the download timestamp to the file the contains the data for a download in progress (usually is filename or part of filename with a different extension). Once the download completes, the download in progress file disappears (I would think it is renamed) and the downloaded file with correct timestamp and filename become available.

I am thinking that the reason such download management applications append the acquired timestamp early in the download process might be to try to avoid compilations that might arise later in the download process (like file locked or in use by security software).

If the PDMTS were to append the acquired file timestamp earlier (perhaps to the download in progress file), perhaps many complications could be avoided (such as the issue when NOD32 antivirus system is installed as described earlier in this thread).

Bluefang

User avatar
 
Posts: 7857
Joined: August 10th, 2005, 2:55 pm
Location: Vermont

Post Posted February 29th, 2012, 9:59 pm

The problem is that Firefox sets the modification time to the current time right before it triggers the "download finished" event, so PDMTS can't do its thing any earlier.

I can try adding in a small delay, but I don't see that helping all that much (it might even make matters worse). If the file is being locked by antivirus software, it could stay licked for seconds. If you delay long enough to get past the AV locking, you run into the issue that something else could modify/move the file.
There have always been ghosts in the machine... random segments of code that have grouped together to form unexpected protocols. Unanticipated, these free radicals engender questions of free will, creativity, and even the nature of what we might call the soul...

zzzzzzzzzz
 
Posts: 133
Joined: October 4th, 2010, 6:04 pm

Post Posted February 29th, 2012, 10:18 pm

Bluefang wrote:The problem is that Firefox sets the modification time to the current time right before it triggers the "download finished" event, so PDMTS can't do its thing any earlier.
So, it would seem that Firefox first sets the file timestamp, then PDMTS sets the file timestamp.

Via Firefox extension, is it possible to modify the Firefox behavior that sets the timestamp such that Firefox would not first set the timestamp?

Bluefang

User avatar
 
Posts: 7857
Joined: August 10th, 2005, 2:55 pm
Location: Vermont

Post Posted February 29th, 2012, 11:18 pm

No. that behavior is in the binary portion of Firefox. That can't be modified without recompiling it.
There have always been ghosts in the machine... random segments of code that have grouped together to form unexpected protocols. Unanticipated, these free radicals engender questions of free will, creativity, and even the nature of what we might call the soul...

Bluefang

User avatar
 
Posts: 7857
Joined: August 10th, 2005, 2:55 pm
Location: Vermont

Post Posted February 29th, 2012, 11:47 pm

Sorry, I misspoke. It's been a while since I looked at the Firefox code.

Firefox does not appear to set the modification time anywhere obvious. However, that is also completely moot. The reason the modification time must be set after the file is fully downloaded is because each time the file is written to (i.e. as it is downloaded), the modification time is updated by the file system.
There have always been ghosts in the machine... random segments of code that have grouped together to form unexpected protocols. Unanticipated, these free radicals engender questions of free will, creativity, and even the nature of what we might call the soul...

zzzzzzzzzz
 
Posts: 133
Joined: October 4th, 2010, 6:04 pm

Post Posted March 2nd, 2012, 12:32 am

Bluefang wrote:Firefox does not appear to set the modification time anywhere obvious. However, that is also completely moot. The reason the modification time must be set after the file is fully downloaded is because each time the file is written to (i.e. as it is downloaded), the modification time is updated by the file system.
Oftentimes, I have checked the properties of files for which their downloads are in progress. I have noticed that the timestamp advertised remains constant until the end. This has been true regardless as to whether a download management application or Firefox is used.

I also ran a trial recently to examine the potential changing of the timestamp of the download in progress. I was unable to verify the changing of the timestamp of the file(s) in progress. The timestamp was the same for each check of the respective file(s). The checks were at least 60 seconds apart. The download took less than an hour to complete. The system clock was not fixed to be constant. I used Windows 2000 Professional with Service Pack 4 and also Windows XP Professional with Service Pack 2 with NTFS partitions.

I do note that a finished download file (after Firefox is finished with it) has the timestamp at or shortly around the time the file download completes when PDMTS is not used and Firefox is used.

After a quick search using Google, I found documentation on the Microsoft website that provides some related information. The documentation was available at http://msdn.microsoft.com/en-us/library ... 85%29.aspx . The documentation seems to indicate (as an inference) that a file time of a file being written to is often not updated (while its "handle" is open).

Do you notice different behavior Bluefang? (Perhaps something is different on your Linux operating system (assuming from your User Agent string))

ake79
 
Posts: 1344
Joined: February 17th, 2007, 6:05 am

Post Posted March 9th, 2012, 8:51 am

Public service announcement. Newest attempt to get this into Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=733954. Please don't say "Me too!"
My extensions: Save File to | ThumbsDown

Return to Extension/Theme Releases


Who is online

Users browsing this forum: No registered users and 2 guests