bin/60474: restore: spurious "warning: ...: File exists" on incremental restore

["campbell+netbsd%mumble.net@localhost via gnats" <gnats-admin%NetBSD.org@localhost>]

>Number:         60474
>Category:       bin
>Synopsis:       restore: spurious "warning: ...: File exists" on incremental restore
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Jul 21 21:10:00 +0000 2026
>Originator:     Taylor R Campbell
>Release:        current, 11, 10, 9, ...
>Organization:
The NetBSD Restoration, Inc.
>Environment:
>Description:

	It appears that when restoring an incremental level>0 dump on
	top of a level0 dump, restore(8) will spuriously warn about
	directories that already exist:

$ restore -x -f level0.dump
$ restore -x -f level1.dump
...
warning: ./conversion/hg/pkgsrc/.hg/store/data/wayland: File exists
warning: ./conversion/hg/pkgsrc/.hg/store/data/wayland/xwayland: File exists
warning: ./conversion/hg/pkgsrc/.hg/store/data/wayland/foot: File exists
warning: ./conversion/hg/pkgsrc/.hg/store/data/wayland/foot/patches: File exists
...

	The restore(8) man page doesn't address this warning.

	=> If this warning is important to heed, then perhaps the man
	   page should mention it.

	=> But if, as I suspect, this is perfectly normal and to be
	   expected because the directories in question were already
	   created by restoring from the level0 dump, then the warning
	   is actively harmful because it contributes to warning
	   fatigue.

	(Perhaps this isn't an issue for `restore -r' when
	reconstructing a whole file system, rather than extracting part
	of a dump, but a perfectly normal use of `restore -x' should
	also work without warnings too.)

>How-To-Repeat:

	1. Take a level0 dump.
	2. Change some files and directories.
	3. Take a level1 dump.
	4. Extract the level0 dump with restore -x.
	5. Extract the level1 dump on top of it with restore -x.

>Fix:

	Yes, please!