begin  quoting James G. Sack (jim) as of Sun, Aug 17, 2008 at 12:58:43PM -0700:
> SJS wrote:
> > begin  quoting Carl Lowenstein as of Fri, Aug 15, 2008 at 10:23:00PM -0700:
[snip]
> >>                                         I rather like the fact that
> >> wget preserves the original timestamp, since that is a property of the
> >> original file, not of the fact that I downloaded it at some later
> >> time.
> > 
> > That information is not trustworthy, so I'm with Ralph; the time that I
> > downloaded a file is significant, the time that someone else SAYS they
> > touched the file is suspect.
> > 
> > If it were useful, it could be modified and be used to fool me.
> > 
> > If it's not useful, there's no need to worry about it.
> 
> At the risk of pushing the cycle around some more, I notice that this
> thread reveals there is always more than one POV.
 
Surely you mean "valid POV". :)

> This may not add much, but my view is sympathetic to cdl's observation
> about the context being that of syncing with repository sources -- not
> that he used exactly those words.

Um... I missed the thread of your logic. Expand and expound, please?

>                                   The filename, size, and mtime are
> useful metadata for this purpose, despite being both insufficient and
> untrustworthy. These defects can be dealt with in various ways, which
> would be another conversation.

Yes, let's have that conversation.

The filename is just a label that you, the user, can change at will, and
wget will do so as well.  The curl command doesn't even give you that --
you, the user, need to decide on the local filename.

Size should *never* be obtained from the remote source -- it should be
calculated from the object itself, locally, always.  Remote reports of
the purported size should be treated as a guideline for the user, but
not as transmitted metadata.

And we've already discussed mtime.

How do you see these 'defects' being dealt with?

-- 
HTTP is a lousy way to synchronize filesystems - use rsync for that.
Stewart Stremler


-- 
KPLUG-List@kernel-panic.org
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list

Reply via email to