Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 20 Jan 2017 04:52:29 +0000
From:      bugzilla-noreply@freebsd.org
To:        freebsd-amd64@FreeBSD.org
Subject:   [Bug 216127] sbin/restore doesn't honour extended attributes (extattr on ufs)
Message-ID:  <bug-216127-6-JnYZhsF0y1@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-216127-6@https.bugs.freebsd.org/bugzilla/>
References:  <bug-216127-6@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216127

--- Comment #12 from Conrad Meyer <cem@freebsd.org> ---
(In reply to dewayne from comment #11)
> The extended attributes are those from both dump files.  This may be as i=
ntended, or it may not?

I don't know.  It seems like they are just accumulating naively in that cas=
e.

Ordinarily I think restores are expected to happen to a pristine filesystem=
, or
level >0 dumps, from the same source, onto a previous 0-level restore.=20
Conflicting restores are sort of a weird case.

> Though, if we restore the user mode, owner and times of a restored, file;=
 I do wonder if only the ext attributes of the latest recovered file should=
 also replace all previous extended attributes.

That does seem like a reasonable behavior to me.

> I don't have a use case that assists, as my needs are met by overwriting =
the values of the stored keys.  However the testing did reveal something th=
at probably should be explicit (in the doc?).

Probably!  I am probably not the right person to make that change, though, =
as
I'm pretty unfamiliar with restore(8).

--=20
You are receiving this mail because:
You are on the CC list for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-216127-6-JnYZhsF0y1>