On Wed, Mar 17, 2010 at 07:24:54PM +0100, Corinna Vinschen wrote: >On Mar 17 19:15, Denis Excoffier wrote: >> >> On Wed, Mar 17, 2010 at 12:56:12PM +0100, Corinna Vinschen wrote: >> >> >> >> What impact? I don't think there is any standard which requires >> a non >> >> filesystem based stream to have a current timestamp and a tool >> relying >> >> on that might be broken. All our streams which are not backed by a >> >> filesystem w/ valid timestamps have an artificial timestamp of >> >> 2006-12-01 00:00:00. >> The file `algorithm.doc' within the gzip distribution states that >> "If input does not come from a regular disk file, the file >> modification time is set to the time at which compression started.". >> >> This has been reported to the `bug-gzip' mailing list (see >> http://lists.gnu.org/archive/html/bug-gzip/2010-03/msg00000.html). >> In his answer, Eric Blake suggested that the bug might be in >> cygwin1.dll. > >The quote does not imply that the input has to have that modification >date. It only implies that the modification date of the output file >of the compression is set to the time the compression started. That >has nothing to do with the timestamp of the input stream.
Right. And, as far as I can see, there is no mechanism within gzip to set the time to something special if stdin is not a regular file. It always seems to use the time that it gets from fstat(). On linux that apparently is today's date. I guess if we want to be compatible we should change this but it isn't something for 1.7.2. I'll put it on my todo list. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
