What's new in Tarsnap 1.0.35
Oct 18, 2013
- A bug in tarsnap 1.0.34 which could cause tarsnap to crash (segmentation fault or bus error) when encountering network glitches or outages is fixed.
- When tarsnap encounters "insane" filesystems (procfs and other similar synthetic filesystems which are not reasonable to archive), it now archives the filesystem mount point but by default does not recurse into the filesystem. Previous releases (since 1.0.26) did not archive the synthetic filesystem mount point.
New in Tarsnap 1.0.33 (Oct 4, 2012)
- Tarsnap now caches archive metadata blocks in RAM, typically providing a 5x - 10x speedup and reduction in bandwidth usage in the "fsck" operation and when deleting a large number of archives at once.
- Tarsnap's internal "chunk" metadata structure is now smaller, providing a ~10% reduction in usage on 32-bit machines and a ~30% reduction in memory usage on 64-bit machines.
- Tarsnap's --newer* options now correctly descend into old directories in order to look for new files. (But note that tarsnap's snapshotting makes these options unnecessary in most situations.)
- Multiple minor bug fixes and cleanups.
New in Tarsnap 1.0.32 (Oct 4, 2012)
- A bug affecting the handling of the --nodump option on Linux (and in most cases rendering it inoperative) is fixed.
- A workaround has been added for a compiler bug in OS X 10.7 (Lion).
- The NetBSD "kernfs" and "ptyfs" filesystems are now excluded from archival by default.
New in Tarsnap 1.0.31 (Oct 4, 2012)
- A race condition in key generation has been fixed which could allow a newly-generated key file to be read by another local user if the key file is being generated in a world-readable directory and the user running tarsnap-keygen has a umask other than 0066.
- A bug in key generation has been fixed which could allow a newly-generated key file to be read by another local user if they key file is being generated in a world-writable directory (e.g., /tmp).
- Tarsnap now supports Minix.
- Tarsnap now ignores blank lines in key files; line-buffers its output (which makes tarsnap --list-archives | foo more responsive); and prints a progress indicator during tarsnap --fsck.
- Multiple minor bug fixes.
New in Tarsnap 1.0.30 (Oct 4, 2012)
- A bug fix in the handling of readdir errors; in earlier versions, it was theoretically possible for a failing hard drive or other errors in reading directories to result in files being silently omitted from an archive.
- Several bug fixes relating to the handling of @archive directives with mtree files.
- A bug fix to prevent cache directory corruption resulting in tarsnap failing if it was interrupted at exactly the right (wrong) moment in its operation.
- A bug fix to correctly handle ~ in tarsnap -s path substitutions.
- Many more minor bug fixes.
New in Tarsnap 1.0.29 (Oct 4, 2012)
- New tarsnap-keyregen and tarsnap-recrypt utilities have been added for downloading, decrypting, re-encrypting, and re-uploading Tarsnap data (aka. key rotation).
New in Tarsnap 1.0.28 (Oct 4, 2012)
- A critical security bug has been fixed in Tarsnap's chunk encryption code.
New in Tarsnap 1.0.27 (Oct 4, 2012)
- The tarsnap -d and tarsnap --print-stats commands can now take multiple -f options, in which case all the specified archives will be deleted or have their statistics printed.
- When the --dry-run option is used, the -f option is no longer required.
- By default tarsnap will no longer recurse into synthetic filesystems (e.g., procfs). A new --insane-filesystems option disables this behaviour (i.e., allows tarsnap to recurse into synthetic filesystems).
- A new --quiet option to tarsnap disables some usually-harmless warnings.
- A new --configfile option to tarsnap makes it possible to specify an additional configuration file; and a --no-default-config option can instruct tarsnap to not process the default configuration files.
- The ~/.tarsnaprc configuration file and configuration settings which begin with ~ are now processed by expanding ~ to the home directory of the current user. This is a change from the behaviour in tarsnap 1.0.26 and earlier where ~ was expanded based on the $HOME environment variable, and will affect the use of tarsnap under sudo(8).
- The tarsnap --fsck command can now be run if either the delete or write keys are present and no longer attempts to prune corrupted archives from the server.
- A new tarsnap --recover command can be used to recover a checkpointed archive. Checkpointed archives will continue to be automatically recovered when tarsnap -c or tarsnap -d are run.
New in Tarsnap 1.0.26 (May 13, 2010)
- This version brings improvements to the Tarsnap client-server protocol in order to avoid dropped connections (and associated warning messages), a bug fix to the --maxbw-rate family of command-line options, improved documentation, and other minor changes.