SJS wrote: > begin quoting James G. Sack (jim) as of Sun, Aug 17, 2008 at 12:58:43PM > -0700: >> SJS wrote: .. >>> 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". :)
<heh> .. um, actually, I might s/valid/reasonable/ > >> 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? There may be a touch of cumulative retelling error (whisper game, or whatever it's called). Looking at the archives, the originating message simple asked why wget duped the mtime when RS would have preferred an mtime equal to the download time. There may have been some missed/missing/assumed interpolation of the purpose of wget being to mirror source and destination. My last posted remark was intended to mean that I viewed the preservation of the mtime as reasonable for the (assumed) purpose. > >> 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. You are right. I should not have included size with filename and mtime. As an afterthought, might size have a metadata role for sparse files? > > And we've already discussed mtime. > > How do you see these 'defects' being dealt with? > What I was alluding to was having a trust relation with the source, and having an authenticated secure connection for transport. Additionally, I was thinking about crypto-signed metadata manifest(s) as a further check for file validity and copy integrity. I was considering that a hash sh/could be added to the metadata to cover the insufficiency for verifying content. A bit of handwaving, I know, but that's what I was thinking. :-) Regards, ..jim -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
