Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Click here to return to the 'Some clients set the DL date' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Some clients set the DL date
Authored by: VRic on May 10, '05 12:11:04PM

The problem you describe depends on the software used to download files: sure Safari TRIES to set the local file's date to the original's (and fails when the server won't provide that info), but others (like iCab) always set the local file's creation date to its, well, creation date (downloads aren't *copies* in the Finder's sense, as they don't occur between 2 filesystems but from one indeterminate data stream to a file).

I would strongly encourage web browser's authors to pick the only reliable way of dating downloads for reasons noted below. Both methods have benefits, but experience has shown me that *trying* to replicate the original dates was:

(a) not worth the effort - since it often fails or results in meaningless information (for example many files "generated" on the fly server-side revert to the date of DL, which tells nothing of their content's creation date: 2 downloads of the same "file" will then have different dates)

(b) confusing - since (a) means you can't guess the result beforehand (some will have "proper" creation dates and other won't, whatever "proper" means to you, but there's no way you could tell without checking)

(b') even more confusing! - since (a) also means you can't guess AFTER the fact: when, after a few days, you'll have forgotten the instant where you donwloaded a file, there will be absolutely no way of knowing if a file's dates come from the original dates or were reverted to the download date by lack of such info from the server

(c) counter-intuitive and user-hostile - since a user's guess and most likely question wouldn't be the orginal date (unknown to him) but the moment he downloaded the file (I realize this point is debatable because most OTHER means of transfering files dutifully preserve dates, because they actually transfer files between filesystems or provide dedicated front-ends to replicate that effect, but this was never the purpose of HTTP)

(d) mostly useless - since most files downloaded from web pages are archives, which creation dates are usually meaningless to the end user (their content's isn't, but their content will have proper dates after extraction; the archive's dates only have sense for authors and webmasters, who don't use HTTP to transfer files to/from their own sites so they have no problem preserving dates anyway)

(e) extremely annoying in actual use - being forced to use both methods (reverting to Safari when iCab beta 3 still chokes on some pages or when my iCab ads filters prove too harsh), I discovered that for the reasons above Safari's way added close to zero usefulness and a LOT of confusion, while iCab's systematic (thus reliable) dating of downloads allowed plenty convenient uses with minimal brain drain (meaning bozos immediately grasp the idea of sorting by date to find what they just clicked on, and uber-bozos like me soon realize that the delta between creation and modification dates also has meaning, exposing the actual data throughput of the DL, this last feature being probably alien to Safari's temporary-downloads-in-bundles-to-be-replaced-later way of breaking things).

This not to suggest the use of iCab, which has its own set of problems (especially since beta 3 still isn't publicly available even though it dates back to last christmas), but maybe to consider other smarter browsers than Safari, or to file bug reports requesting iCabification of other browsers on that front, too, in addition to download manager, pages saving, content filters, searches, etc.

[ Reply to This | # ]