Date: Fri, 20 Jan 2017 04:38:58 +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-zPcqHzfk3E@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 #11 from dewayne@heuristicsystems.com.au --- (In reply to commit-hook from comment #9) Thank-you for promptly addressing this issue. I've rebuild/installed FreeB= SD 11.0S world & kernel with patches D9206 D9208 and the restore operates as expected. :) Though I did perform additional tests. Firstly I restored the original dump file, and the restore operation successfully restored the ext attributes :)= . I then (fileA has different contents and different extattr in the following): - restored fileA from dump file d.dmp extended attributes m and s # patch t= est -the filesystem is deleted - fileA (same name different content) with attributes m1 and s1 is stored in dump file d2.dmp -filesystem is deleted -fileA is restored from d.dmp -fileA is restored from d2.dmp (fileA with different contents & different extattr) The extended attributes are those from both dump files. This may be as intended, or it may not? 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. I don't have a use case that assists, as my needs are met by overwriting the values of the stored keys.= =20 However the testing did reveal something that probably should be explicit (= in the doc?). --=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-zPcqHzfk3E>