the warning was annoying for people with a lot of such items and
they can not do anything about it anyway.
thus, just document this as a limitation.
(cherry picked from commit e674822888)
do no read/archive bsdflags: borg create --nobsdflags ...
do not extract/set bsdflags: borg extract --nobsdflags ...
use cases:
- fs shows wrong / random bsdflags (bug in filesystem)
- fs does not support bsdflags anyway
- already archived bsdflags are wrong / unwanted
- borg shows any sort of unwanted effect due to get_flags, esp. on Linux
the nodump flag ("do not backup this file") is not honoured any more by
default because this functionality (esp. if it happened by error or
unexpected) was rather confusing and unexplainable at first to users.
if you want that "do not backup NODUMP-flagged files" behaviour, use:
borg create --exclude-nodump ...
(cherry picked from commit 10adadf685)
Looks like under unfortunate circumstances, these files could become
0 byte files (see #3158). SaveFile usage should prevent that.
(cherry picked from commit 0190abff81)
when doing in-file checkpointing, borg creates *.borg_part_N files.
complete_file = part_1 + part_2 + ... + part_N
the source item for recreate already has a precomputed (total) size
member, thus we must force recomputation from the (partial) chunks
list to correct the size to be the part's size only.
borg create avoided this problem by computing the size member after
writing all the parts. this is now not required any more.
the bug is mostly cosmetic, borg check will complain, borg extract on
a part file would also complain. but all the complaints only refer to
the wrong metadata of the part files, the part files' contents are
correct.
usually you will never extract or look at part files, but only deal
with the full file, which will be completely valid, all metadata and
content.
you can get rid of the archives with these cosmetic errors by running
borg recreate on them with a fixed borg version. the old part files
will get dropped (because they are usually ignored) and any new part
file created due to checkpointing will be correct.
(cherry picked from commit 9d6b125e98)
opening a device file for a non-existing device can be very slow.
symlinks will make the open() call fail as it is using O_NOFOLLOW.
also: lstat -> stat(..., follow_symlinks=False) like everywhere else.
(cherry picked from commit a6ee4e9aed)
filenames like ..foobar are valid, so, to detect stuff in upper dirs,
we need to include the path separator and check if it starts with '../'.
(cherry picked from commit 60e9249100)
if it is not significantly better compressed, we just store lz4
compressed data (which we already have computed anyway), because
that at least decompressed super fast.
(cherry picked from commit 011e0fd3fa)
