Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

whiteout file type? #7174

Open
ThomasWaldmann opened this issue Nov 28, 2022 · 2 comments
Open

whiteout file type? #7174

ThomasWaldmann opened this issue Nov 28, 2022 · 2 comments
Labels

Comments

@ThomasWaldmann
Copy link
Member

ThomasWaldmann commented Nov 28, 2022

Accidentally stumbled over a file type borg does not support yet: a whiteout (used by overlay fs)

Infos:

Linux: has a hack avoiding a new file type, using a char dev 0:0 for file whiteouts and an xattr for directory whiteouts
macOS: has whiteouts
FreeBSD: has support for whiteouts, separate file type DT_WHT
OpenBSD: no whiteouts
NetBSD: ?

Is there a need for backing up / restoring whiteouts?

  • for a mounted overlay fs, it should be backed up as visible to the user (no whiteouts visible)
  • can one access the layers individually, so that WHT files would become visible (on BSD)?
@ThomasWaldmann ThomasWaldmann self-assigned this Dec 3, 2022
@ThomasWaldmann
Copy link
Member Author

ThomasWaldmann commented Dec 3, 2022

We could add a branch checking for stat.S_ISWHT inside borg create (that stat method exists on all recent pythons and I checked win32, cygwin, linux: all actually have stat.S_ISWHT).

Without that branch, borg will just emit a warning about Unknown file type: <path>.

Options:

  • keep code as is (emit warning about unknown file type)
  • silently skip the file (like borg does for sockets / solaris doors / solaris event ports) - if we are sure backing up such files makes no sense.
  • archive it (and also add support to restore it) - in case this makes sense / there is a use case for this.

Currently, keeping this as is (warning) is the best option until someone using this type of files adds more insights here about the desired behaviour to this ticket.

@ThomasWaldmann ThomasWaldmann removed their assignment Dec 3, 2022
@enkore
Copy link
Contributor

enkore commented Aug 29, 2023

Whiteouts are mostly used these days in container layers (which may use overlayfs, depending on the container runtime), so they're not uncommon per se, but you'd normally not include container storages in backups (which can have unpacked layers in them). Container image files, which some people might want to back up, are just normal files and pack each layer in a tar file, including the respective whiteouts. If you look at these backing directories through the lens of an overlayfs, whiteouts are processed by overlayfs, and not visible to the user.

I doubt there's much use to this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants