Looking at the OverlayFS
[docs](https://docs.kernel.org/filesystems/overlayfs.html#renaming-directories)
some more, specifically at the section covering `redirect_dir`, it mentions the
following (emphasis mine):
> return EXDEV error: this error is returned by rename(2) when trying to move a
> file or directory across filesystem boundaries. Hence ***applications are
> usually prepared to handle this error*** (mv(1) for example recursively
> copies the directory tree). This is the default behavior.
Obviously, since `mv(1)` falls back to copying when crossing filesystem
boundaries, it handles this property of OverlayFS transparently. That makes
sense for a utility like `mv(1)` where you expect users to want to move stuff
across filesystems, however in our
[code](https://github.com/rpm-software-management/rpm/blob/34cb5ee92276058f68f6d3fb1c345b22992c28a8/lib/rpmdb.c#L2295),
we typically operate on the same filesystem when backing up the current rpmdb
instance in the same directory.
Historically, before OverlayFS was a thing, there was no reason to assume
otherwise, as you wouldn't normally have an "artificial" filesystem boundary
within the same directory.
Since OverlayFS is now a mature and widely deployed filesystem (especially in
the container space), adjusting our `--rebuilddb` logic to handle the EXDEV
error actually seems quite reasonable, after all.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2905#discussioncomment-8456276
You are receiving this because you are subscribed to this thread.
Message ID:
<rpm-software-management/rpm/repo-discussions/2905/comments/8456...@github.com>
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
