review metadata processing: empty/0 vs not knowing

[ThomasWaldmann]

the code could be reviewed whether this distinction is cleanly handled everywhere.

borg create has some switches like --noacls, --noxattrs, --nobsdflags, --noatime that can be used to not store such metadata into the archive.

as a consequence, the state represented by the archive says e.g. "I do not know about ACLs" which is a different thing than "there were no ACLs".

[ThomasWaldmann]

bsdflags

borg 1.2 behaviour, create

• with --noflags the bsdflags are not read and the value is set to 0
• otherwise the flags value is read from the file
• bsdflags value will only get stored into the item attrs if the flags value is not 0

Problems:

• we can not differentiate between "we do not know / we did not read them" and "we read them and there was nothing special (0)"

planned borg 2.0 behaviour, create

• if we do not know / if we do not read them, we do not store bsdflags into the item attrs
• if we read them and thus do know, we always store the value into the item attrs, even if it is 0.

borg 1.2 behaviour, extract

• with --noflags, no bsdflags will be set (no matter what is in the item)
• if no bsdflags are stored in the item (no such key), no bsdflags will be set
• otherwise, set the flags to item.bsdflags

planned borg 2.0 behaviour, extract

• (same as in 1.2)
• note: due to the different "create" behaviour (storing bsdflags with 0 value), this would call set_flags(path, 0, fd=fd) - is that a problem? should we not call this if the value is 0?

[ThomasWaldmann]

xattrs

borg 1.2 behaviour, create

• with --noxattrs, the xattrs are not read and no xattrs key is stored into the item attrs
• otherwise the xattrs are read from the file
• xattrs are only stored into the item if the dict is not empty

planned borg 2.0 behaviour, create

• if we do not know / if we do not read them, we do not store xattrs into the item attrs
• if we read them and thus do know, we always store the value into the item attrs, even if it is the empty dict.

borg 1.2 behaviour, extract

• with --noxattrs, no xattrs will be set (no matter what is in the item)
• if no xattrs are stored in the item (no such key), no xattrs will be set
• otherwise set all xattrs (iterate over all keys, values in the xattrs dict)

planned borg 2.0 behaviour, extract

• same as in 1.2
• note: the iteration might be over keys/values of an empty dict, but the end result will be as desired.

[ThomasWaldmann]

ACLs

borg 1.2 behaviour, create

• with --noacls, the ACLs are not read and no acl keys are stored into the item attrs
• otherwise the ACLs are read from the file
• acls are only stored into the item if they were readable and convertable to text (not NULL)

planned borg 2.0 behaviour, create

• same as in 1.2

borg 1.2 behaviour, extract

• with --noacls, no ACLs will be set (no matter what is in the item)
• if no acl is stored in the item (no such key), no acl will be set
• otherwise set the acl as in the item

planned borg 2.0 behaviour, extract

• same as in 1.2

Looks like no behaviour change is needed here. The code got some refactors though, see commit comment.

[ThomasWaldmann]

timestamps

borg 1.2, create

• always store mtime into the item
• by default, do not store atime into the item. when using --atime, store atime into the item.
• store ctime into the item, except when using --noctime then do not store it.
• if we have birthtime in stat results, store it into item, except if --nobirthtime is given

planned borg 2.0, create

• same
• ctime - shall we change something there?

borg 1.2, extract

• always expect item.mtime to be present
• atime: use item.atime if present otherwise use value of item.mtime
• ctime: we don't do anything with this. guess we can't do anything with this.
• birthtime: if present, use it, otherwise do nothing related to it

planned borg 2.0, extract

• same
• ctime - shall we change something there?

[ThomasWaldmann]

permissions

borg 1.2, create

• always store mode, uid, gid
• --numeric-ids store user=None and group=None
• otherwise store user=uid2user(uid) and group=gid2group(gid) - if the lookup fails, this stores None

planned borg 2.0, create

• similar, but:
• rather do not store user/group at all for --numeric-ids
• if the user/group name lookup fails, rather do not store user/group (== do not store None)

borg 1.2, extract

• --numeric-ids: use item.uid and item.gid (but avoid < 0)
• otherwise, use user2uid(item.user) and group2gid(item.group) if they succeed else use item.uid/gid.

planned borg 2.0, extract

• same for --numeric-ids
• otherwise: similar to above, but handle missing user/group like it being None, triggering fallback to item.uid/gid.