Mail Archives: cygwin/2010/03/17/13:43:49
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
- Raw text -