Spool directory holds encrypted packets received from
remote nodes and queued for sending to them. It has the following
example structure with just single outbound (
LYT64MWSNDK34CVYOO7TA6ZCJ3NWI2OUDBBMX2A4QWF34FIRY4DQ to the node
spool/2WHBV3TPZHDOZGUJEH563ZEK7M33J4UESRFO4PDKWD5KZNPROABQ/toss.lock spool/2WHBV3TPZHDOZGUJEH563ZEK7M33J4UESRFO4PDKWD5KZNPROABQ/rx.lock spool/2WHBV3TPZHDOZGUJEH563ZEK7M33J4UESRFO4PDKWD5KZNPROABQ/rx/ spool/2WHBV3TPZHDOZGUJEH563ZEK7M33J4UESRFO4PDKWD5KZNPROABQ/tx.lock spool/2WHBV3TPZHDOZGUJEH563ZEK7M33J4UESRFO4PDKWD5KZNPROABQ/tx/LYT64MWSNDK34CVYOO7TA6ZCJ3NWI2OUDBBMX2A4QWF34FIRY4DQ spool/tmp
directory contains various temporary files that under normal circumstances are renamed to necessary files inside other directories. All directories in spool have to be on the same filesystem for working renaming.
is an example Base32-encoded neighbour identifier.
directories are for incoming and outgoing encrypted packets. rx contains currently unfinished, non-checked, unprocessed, etc packets.
Lock files. Only single process can work with rx/tx directories at once.
is an example encrypted packet. Its filename is Base32 encoded Merkle Tree Hashing hash of the whole contents. It can be integrity checked anytime.
is an example partly received file. It can appear only when online transfer is used. Its filename is sent by remote side and until file is fully downloaded – it plays no role.
non-checksummed (NoCK) fully received file. Its checksum is
verified against its filename either by
by working online daemons. If it is correct, then its extension is trimmed.
nncp-toss utility can be invoked with -seen
option, leading to creation of 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
If no nohdr option is enabled in configuration file,
then 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
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
There is a hack: you can create more dense hdr/ allocation by
removing all hdr/ files and then running
that will recreate them. In many cases many hdr/ files will be
allocated more or less linearly on the disk, decreasing listing time