diff options
Diffstat (limited to 'Y2K_INFO')
| -rw-r--r-- | Y2K_INFO | 34 |
1 files changed, 34 insertions, 0 deletions
diff --git a/Y2K_INFO b/Y2K_INFO new file mode 100644 index 0000000..55fd56a --- /dev/null +++ b/Y2K_INFO | |||
| @@ -0,0 +1,34 @@ | |||
| 1 | |||
| 2 | Y2K status of bzip2 and libbzip2, versions 0.1, 0.9.0 and 0.9.5 | ||
| 3 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
| 4 | |||
| 5 | Informally speaking: | ||
| 6 | bzip2 is a compression program built on top of libbzip2, | ||
| 7 | a library which does the real work of compression and | ||
| 8 | decompression. As far as I am aware, libbzip2 does not have | ||
| 9 | any date-related code at all. | ||
| 10 | |||
| 11 | bzip2 itself copies dates from source to destination files | ||
| 12 | when compressing or decompressing, using the 'stat' and 'utime' | ||
| 13 | UNIX system calls. It doesn't examine, manipulate or store the | ||
| 14 | dates in any way. So as far as I can see, there shouldn't be any | ||
| 15 | problem with bzip2 providing 'stat' and 'utime' work correctly | ||
| 16 | on your system. | ||
| 17 | |||
| 18 | On non-unix platforms (those for which BZ_UNIX in bzip2.c is | ||
| 19 | not set to 1), bzip2 doesn't even do the date copying. | ||
| 20 | |||
| 21 | Overall, informally speaking, I don't think bzip2 or libbzip2 | ||
| 22 | have a Y2K problem. | ||
| 23 | |||
| 24 | Formally speaking: | ||
| 25 | I am not prepared to offer you any assurance whatsoever | ||
| 26 | regarding Y2K issues in my software. You alone assume the | ||
| 27 | entire risk of using the software. The disclaimer of liability | ||
| 28 | in the LICENSE file in the bzip2 source distribution continues | ||
| 29 | to apply on this issue as with every other issue pertaining | ||
| 30 | to the software. | ||
| 31 | |||
| 32 | Julian Seward | ||
| 33 | Cambridge, UK | ||
| 34 | 25 August 1999 | ||
