From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Sun, 2 Mar 2003 04:59:58 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 60 ************************************************** Saturday 01 March 2003 Number 60 ************************************************** Subjects for today 1 Re: BZIP2 : Maynard" 2 Re: BZIP2 : Maynard" 3 Re: INFO dir : John Poltorak 4 Re: INFO dir : Andreas Buening 5 BZIP2 : John Poltorak 6 Re: BZIP2 : John Poltorak **= Email 1 ==========================** Date: Sun, 02 Mar 2003 09:25:52 -0600 (CST) From: "Maynard" Subject: Re: BZIP2 On Sun, 2 Mar 2003 14:26:03 +0000, John Poltorak wrote: >There is a bug in BZIP2 whereby the date of the compressed file is the >date the compression is made rather than the date of the original file. >Can anyone come up with a fix for this? Actually, it's the DEcompression date, and is in all likelihood supplied by the OS as the file is a new creation. Looking at the distribution file Y2K_INFO, ... bzip2 itself copies dates from source to destination files when compressing or decompressing, using the 'stat' and 'utime' UNIX system calls. It doesn't examine, manipulate or store the dates in any way. So as far as I can see, there shouldn't be any problem with bzip2 providing 'stat' and 'utime' work correctly on your system. On non-unix platforms (those for which BZ_UNIX in bzip2.c is not set to 1), bzip2 doesn't even do the date copying. I'm guessing that the bzip2 code wants to use 'stat' to determine the original file's datestamp; and 'utime' to reset the date after decompress. [stat.h is in posix2] -- Maynard **= Email 2 ==========================** Date: Sun, 02 Mar 2003 11:17:33 -0600 (CST) From: "Maynard" Subject: Re: BZIP2 On Sun, 2 Mar 2003 16:03:38 +0000, John Poltorak wrote: >> On non-unix platforms (those for which BZ_UNIX in bzip2.c is >> not set to 1), bzip2 doesn't even do the date copying. >> >> >> I'm guessing that the bzip2 code wants to use 'stat' to determine the >> original file's datestamp; and 'utime' to reset the date after >> decompress. >> >> [stat.h is in posix2] >So, what are you suggesting needs to be changing to correct the >datestamping error? It would seem that the course of action would be to find a utime library and try making with BZ_UNIX = 1 using utime and stat -- Maynard **= Email 3 ==========================** Date: Sun, 2 Mar 2003 13:04:00 +0000 From: John Poltorak Subject: Re: INFO dir On Sun, Mar 02, 2003 at 01:49:07PM +0100, Andreas Buening wrote: > John Poltorak wrote: > > > > On Fri, Feb 28, 2003 at 10:27:35PM +0100, Andreas Buening wrote: > > [snip] > > > > ./configure --infodir=/share/usr/info > > > > > > or if you don't want to reconfigure > > > > > > make install infodir=/share/usr/info > > > > Does this work for you? > > > > The infodir option seems to get ignored when I use it. > > Can't be. ;-) > If you go into the doc subdirectory, enter > "make install info=/share/usr/info" then the .info file is still > copied into /usr/info? Which package? I think this one does:- ftp://ftp.gnu.org/pub/gnu/termcap/termcap-1.3.1.tar.gz > > Bye, > Andreas > > -- > One OS to rule them all, One OS to find them, > One OS to bring them all and in the darkness bind them > In the Land of Mordor where the Shadows lie. -- John **= Email 4 ==========================** Date: Sun, 02 Mar 2003 13:49:07 +0100 From: Andreas Buening Subject: Re: INFO dir John Poltorak wrote: > > On Fri, Feb 28, 2003 at 10:27:35PM +0100, Andreas Buening wrote: [snip] > > ./configure --infodir=/share/usr/info > > > > or if you don't want to reconfigure > > > > make install infodir=/share/usr/info > > Does this work for you? > > The infodir option seems to get ignored when I use it. Can't be. ;-) If you go into the doc subdirectory, enter "make install info=/share/usr/info" then the .info file is still copied into /usr/info? Which package? Bye, Andreas -- One OS to rule them all, One OS to find them, One OS to bring them all and in the darkness bind them In the Land of Mordor where the Shadows lie. **= Email 5 ==========================** Date: Sun, 2 Mar 2003 14:26:03 +0000 From: John Poltorak Subject: BZIP2 There is a bug in BZIP2 whereby the date of the compressed file is the date the compression is made rather than the date of the original file. Can anyone come up with a fix for this? -- John **= Email 6 ==========================** Date: Sun, 2 Mar 2003 16:03:38 +0000 From: John Poltorak Subject: Re: BZIP2 On Sun, Mar 02, 2003 at 09:25:52AM -0600, Maynard wrote: > On Sun, 2 Mar 2003 14:26:03 +0000, John Poltorak wrote: > > >There is a bug in BZIP2 whereby the date of the compressed file is the > >date the compression is made rather than the date of the original file. > > >Can anyone come up with a fix for this? > > Actually, it's the DEcompression date, and is in all likelihood > supplied by the OS as the file is a new creation. > > Looking at the distribution file Y2K_INFO, ... > > bzip2 itself copies dates from source to destination files > when compressing or decompressing, using the 'stat' and 'utime' > UNIX system calls. It doesn't examine, manipulate or store the > dates in any way. So as far as I can see, there shouldn't be any > problem with bzip2 providing 'stat' and 'utime' work correctly > on your system. > > On non-unix platforms (those for which BZ_UNIX in bzip2.c is > not set to 1), bzip2 doesn't even do the date copying. > > > I'm guessing that the bzip2 code wants to use 'stat' to determine the > original file's datestamp; and 'utime' to reset the date after > decompress. > > [stat.h is in posix2] So, what are you suggesting needs to be changing to correct the datestamping error? > -- Maynard -- John