{now} and {utcnow} should point to the same exact momemt, but they don't
because .now() and .utcnow() create two different objects at different
times. Although the difference will be on the order of microseconds on all
but the slowest machines, this bug still tickles my inner pedant...
- move stuff to platform.base (should be platform independent according
to the docs).
- bump platform API version
- parseformat: import fqdn from platform instead of recomputing it
This is not yet fixing #3471, just a preparation for it.
This command works similarly to "git config" - it parses repo and
cache configs to get, set, and delete values. It only works on local
repos so a malicious client can't e.g. override their storage quota
or reset the append_only flag.
Add tests for borg config
Add documentation for borg config
Change manual config edits -> borg config
There were a couple places in the documentation where it was advised
to edit the repository or cache config file, a process that is stream-
lined by borg config.
You can now control the files cache mode using this option:
--files-cache={ctime,mtime,size,inode,rechunk,disabled}*
(only some combinations are supported)
Previously, only these modes were supported:
- mtime,size,inode (default of borg < 1.1.0rc4)
- mtime,size (by using --ignore-inode)
- disabled (by using --no-files-cache)
Now, you additionally get:
- ctime alternatively to mtime (more safe), e.g.:
ctime,size,inode (this is the new default of borg >= 1.1.0rc4)
- rechunk (consider all files as changed, rechunk them)
Deprecated:
- --ignore-inodes (use modes without "inode")
- --no-files-cache (use "disabled" mode)
The tests needed some changes:
- previously, we use os.utime() to set a files mtime (atime) to specific
values, but that does not work for ctime.
- now use time.sleep() to create the "latest file" that usually does
not end up in the files cache (see FAQ)
like yyyy-mm-ddThh:mm:ss - no tz yet, this likely needs more refactoring
to tz aware and utc datetime objects everywhere, currently there are
naive datetime objects and also localtime at quite some places.
like yyyy-mm-ddThh:mm:ss - no tz yet, this likely needs more refactoring
to tz aware and utc datetime objects everywhere, currently there are
naive datetime objects and also localtime at quite some places.
like yyyy-mm-ddThh:mm:ss - no tz yet, this likely needs more refactoring
to tz aware and utc datetime objects everywhere, currently there are
naive datetime objects and also localtime at quite some places.
