aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorB. Watson <urchlay@slackware.uk>2025-12-10 16:31:51 -0500
committerB. Watson <urchlay@slackware.uk>2025-12-10 16:31:51 -0500
commitaa01b328ed283ba6247e7c222e67874ca1e5e325 (patch)
tree74adf5fe2dde7db31fd8b99b58062c21161ca756
parent9dacd9e8484e1f31828b597deaa6ac0b9836c652 (diff)
downloadalftools-aa01b328ed283ba6247e7c222e67874ca1e5e325.tar.gz
Tweak alf man page.
-rw-r--r--src/alf.117
-rw-r--r--src/alf.rst17
2 files changed, 20 insertions, 14 deletions
diff --git a/src/alf.1 b/src/alf.1
index f3a69d7..485aea9 100644
--- a/src/alf.1
+++ b/src/alf.1
@@ -247,16 +247,17 @@ compress/decompress such files, and you\(aqd have to have a hard disk and
a DOS capable of handling multi\-megabyte files...
.SS Performance
.sp
-Performance is pretty good, as of alftools\-0.3.0. For small files
+Performance is pretty good, as of alftools\-0.4.0. For small files
like you\(aqd use on an Atari (up to 50KB), it\(aqs basically instantaneous
-(0.008 seconds) on the author\(aqs modest i7 workstation. For a 1MB
-text file, it takes 0.026 sec; for 1MB of random garbage, it\(aqs 0.043
-sec (and the resulting ALF file is 36% larger than the garbage).
+(0.008 seconds) on the author\(aqs modest i7 workstation. For a 1MB text
+file, it takes 0.026 sec (faster than \fBarc\fP!). For 1MB of random
+garbage, it\(aqs 0.043 sec (and the resulting ALF file is 36% larger than
+the garbage).
.sp
By comparison, \fBzip\fP takes 0.06 seconds to compress the 1MB text file,
and 0.03 sec for the 1MB randomness (and the compressed file is still
-larger than the input, but only by 312 bytes). The speed demon is \fBarc\fP:
-it compresses the text file in 0.03s, and it\(aqs smart enough to \fInot\fP
+larger than the input, but only by 312 bytes). \fBarc\fP
+compresses the text file in 0.03s, and it\(aqs smart enough to \fInot\fP
compress the random garbage (it uses the \(aqstore\(aq method, which \fBalf\fP
doesn\(aqt have).
.SS Timestamps
@@ -268,7 +269,9 @@ options above). There\(aqs no way to store timezone or daylight savings
info in the \fIALF\fP file.
.sp
The year stored in the \fIALF\fP file doesn\(aqt have a Y2K problem. It does,
-however, have a Y2108 problem: the range is from 1980 to 2107.
+however, have a Y2108 problem: the range is from 1980 to 2107. Files
+with timestamps outside this range will have a zero (invalid) date in the
+\fIALF\fP header, and \fBunalf\fP will display the date as \fI<none>\fP\&.
.sp
The timestamp only has 2\-second resolution. Files with odd\-numbered
seconds in the \fImtime\fP will have the number before that (1 => 0, 31 =>
diff --git a/src/alf.rst b/src/alf.rst
index 5d6114a..32a2cd3 100644
--- a/src/alf.rst
+++ b/src/alf.rst
@@ -218,16 +218,17 @@ a DOS capable of handling multi-megabyte files...
Performance
-----------
-Performance is pretty good, as of alftools-0.3.0. For small files
+Performance is pretty good, as of alftools-0.4.0. For small files
like you'd use on an Atari (up to 50KB), it's basically instantaneous
-(0.008 seconds) on the author's modest i7 workstation. For a 1MB
-text file, it takes 0.026 sec; for 1MB of random garbage, it's 0.043
-sec (and the resulting ALF file is 36% larger than the garbage).
+(0.008 seconds) on the author's modest i7 workstation. For a 1MB text
+file, it takes 0.026 sec (faster than **arc**\!). For 1MB of random
+garbage, it's 0.043 sec (and the resulting ALF file is 36% larger than
+the garbage).
By comparison, **zip** takes 0.06 seconds to compress the 1MB text file,
and 0.03 sec for the 1MB randomness (and the compressed file is still
-larger than the input, but only by 312 bytes). The speed demon is **arc**\:
-it compresses the text file in 0.03s, and it's smart enough to *not*
+larger than the input, but only by 312 bytes). **arc**
+compresses the text file in 0.03s, and it's smart enough to *not*
compress the random garbage (it uses the 'store' method, which **alf**
doesn't have).
@@ -241,7 +242,9 @@ options above). There's no way to store timezone or daylight savings
info in the *ALF* file.
The year stored in the *ALF* file doesn't have a Y2K problem. It does,
-however, have a Y2108 problem: the range is from 1980 to 2107.
+however, have a Y2108 problem: the range is from 1980 to 2107. Files
+with timestamps outside this range will have a zero (invalid) date in the
+*ALF* header, and **unalf** will display the date as *<none>*.
The timestamp only has 2-second resolution. Files with odd-numbered
seconds in the *mtime* will have the number before that (1 => 0, 31 =>