]> Cypherpunks.ru repositories - nncp.git/blobdiff - doc/spool.texi
Unify @ref and @command usage
[nncp.git] / doc / spool.texi
index 76c1f596b27205ace36ad503616d0da8f52db8db..c7ddb31a0e5910f31dddff247aa36bec3732d4e3 100644 (file)
@@ -54,15 +54,15 @@ file is fully downloaded -- it plays no role.
 @cindex nock files
 @item LYT64MWSNDK34CVYOO7TA6ZCJ3NWI2OUDBBMX2A4QWF34FIRY4DQ.nock
 non-checksummed (NoCK) @strong{fully} received file. Its checksum is
-verified against its filename either by @ref{nncp-check}, or by working
-online daemons. If it is correct, then its extension is trimmed.
+verified against its filename either by @command{@ref{nncp-check}}, or
+by working online daemons. If it is correct, then its extension is trimmed.
 
 @cindex seen files
 @item seen/LYT64MWSNDK34CVYOO7TA6ZCJ3NWI2OUDBBMX2A4QWF34FIRY4DQ
-@ref{nncp-toss} utility can be invoked with @option{-seen} option,
-leading to creation of @file{seen/} files, telling that the file with
-specified hash has already been processed before. It could be useful
-when there are use-cases where multiple ways of packets transfer
+@command{@ref{nncp-toss}} utility can be invoked with @option{-seen}
+option, leading to creation of @file{seen/} files, telling that the file
+with specified hash has already been processed before. It could be
+useful when there are use-cases where multiple ways of packets transfer
 available and there is possibility of duplicates reception. You have to
 manually remove them, when you do not need them (probably because they
 are expired).
@@ -74,14 +74,14 @@ If no @ref{CfgNoHdr, nohdr} option is enabled in configuration file,
 then @file{hdr/} files are automatically created for every ordinary
 (fully received and checksummed) packet. It literally contains just the
 header of the corresponding packet. It will be automatically created
-even during simple @ref{nncp-stat} call. On filesystems with big
-blocksize (ZFS for example) it can greatly help listing the packets in
-directories, because it prevents unnecessary read-amplification. On
+even during simple @command{@ref{nncp-stat}} call. On filesystems with
+big blocksize (ZFS for example) it can greatly help listing the packets
+in directories, because it prevents unnecessary read-amplification. On
 other filesystems probably it won't help at all, or even harm
 performance.
 
 There is a hack: you can create more dense @file{hdr/} allocation by
-removing all @file{hdr/} files and then running @command{nncp-stat},
+removing all @file{hdr/} files and then running @command{@ref{nncp-stat}},
 that will recreate them. In many cases many @file{hdr/} files will be
 allocated more or less linearly on the disk, decreasing listing time
 even more.