Roy J. Tellason wrote in a message to Bill Dennison:
 RJT> Yep.  And therefore you never know what you've got and if it's 
 RJT> the latest compared to what's out there.  Heck,  even my bbs 
 RJT> software shows the date of a file!  If I snag something off the 
 RJT> 'net,  the date stamp on it ends up being the date I got it,  
 RJT> not the original date of the file. They've got a ways to go yet 
 RJT> before they get it right,  I think...
TCP/IP antedates MS-DOS, and not all computers of that era maintained such 
information about files as their creation date or last modified date.  If you 
want to preserve directory information about a file, then the general 
solution is not to build such information into the file transfer protocol, 
but rather to attach directory information to the file itself.  It is much 
better for file transfer protocols to be able to treat files as streams of 
raw binary data, without regard to machine dependent-features such as how 
many bits are in each word or how date and time information are encoded.
Numerous schemes exist for binding files with their directory information, 
including archivers such as "tar" in the Unix world and combined 
archiver/compressors such as "zip" in the DOS world.  If you now start 
griping about the fact that the file transfer protocol fails to preserve the 
datestamp on the wrapper archive file itself, then that sort of misses the 
point.
If you want to reset the datestamp on an archive file, most archiving 
programs provide for a way to set the archive date to the date of the most 
recent file found inside.  For example, the Info-ZIP "zip" archiver has the 
"-o" switch to do exactly this.
 
-- Mike
--- 
---------------