## Spool directory ¶

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 (`tx`) packet `LYT64MWSNDK34CVYOO7TA6ZCJ3NWI2OUDBBMX2A4QWF34FIRY4DQ` to the node `2WHBV3TPZHDOZGUJEH563ZEK7M33J4UESRFO4PDKWD5KZNPROABQ`:

    spool/2WHBV3TPZHDOZGUJEH563ZEK7M33J4UESRFO4PDKWD5KZNPROABQ/toss.lock
    spool/2WHBV3TPZHDOZGUJEH563ZEK7M33J4UESRFO4PDKWD5KZNPROABQ/rx.lock
    spool/2WHBV3TPZHDOZGUJEH563ZEK7M33J4UESRFO4PDKWD5KZNPROABQ/rx/
    spool/2WHBV3TPZHDOZGUJEH563ZEK7M33J4UESRFO4PDKWD5KZNPROABQ/tx.lock
    spool/2WHBV3TPZHDOZGUJEH563ZEK7M33J4UESRFO4PDKWD5KZNPROABQ/tx/LYT64MWSNDK34CVYOO7TA6ZCJ3NWI2OUDBBMX2A4QWF34FIRY4DQ
    spool/tmp

`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.

`2WHBV3TPZHDOZGUJEH563ZEK7M33J4UESRFO4PDKWD5KZNPROABQ`

  is an example Base32-encoded neighbour identifier.

`rx, tx` ¶

  directories are for incoming and outgoing encrypted packets. `rx` contains currently unfinished, non-checked, unprocessed, etc packets.

`toss.lock, rx.lock, tx.lock` ¶

  Lock files. Only single process can work with `rx`/`tx` directories at once.

`LYT64MWSNDK34CVYOO7TA6ZCJ3NWI2OUDBBMX2A4QWF34FIRY4DQ`

  is an example encrypted packet. Its filename is Base32 encoded Merkle Tree Hashing hash of the whole contents. It can be integrity checked anytime.

`LYT64MWSNDK34CVYOO7TA6ZCJ3NWI2OUDBBMX2A4QWF34FIRY4DQ.part` ¶

  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.

`LYT64MWSNDK34CVYOO7TA6ZCJ3NWI2OUDBBMX2A4QWF34FIRY4DQ.nock` ¶

  non-checksummed (NoCK) fully received file. Its checksum is verified against its filename either by `nncp-check`, or by working online daemons. If it is correct, then its extension is trimmed.

`seen/LYT64MWSNDK34CVYOO7TA6ZCJ3NWI2OUDBBMX2A4QWF34FIRY4DQ` ¶

  `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 are expired).

`hdr/LYT64MWSNDK34CVYOO7TA6ZCJ3NWI2OUDBBMX2A4QWF34FIRY4DQ`

  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 performance.

  There is a hack: you can create more dense `hdr/` allocation by removing all `hdr/` files and then running `nncp-stat`, that will recreate them. In many cases many `hdr/` files will be allocated more or less linearly on the disk, decreasing listing time even more.

`tx/ack/LYT64MWSNDK34CVYOO7TA6ZCJ3NWI2OUDBBMX2A4QWF34FIRY4DQ`

  If tossing was performed with `-gen-ack` option, then for each generated ACKnowledgements packet there will be corresponding empty `ack/` file. ACK outbound packets needs to be deleted after the transmission, but since they are stored encrypted in the spool, there needs to be some kind of knowledge what packets are ACK ones. Both ACK and corresponding `ack/` files are removed by `nncp-rm -ack` command.