[Rpm-maint] [rpm-software-management/rpm] rpm --rebuilddb in an overlayfs without redirect_dir=on (Discussion #2905)

[Michal Domonkos]

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/8456276 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20240213/d89ca16e/attachment.html>