Date: Thu, 27 Jun 2002 06:10:03 -0700 (PDT) From: Michael Adler <mad1@tapil.com> To: freebsd-bugs@FreeBSD.org Subject: Re: bin/39849: /sbin/restore fails to overwrite files with schg flag set Message-ID: <200206271310.g5RDA3Rx038996@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/39849; it has been noted by GNATS. From: Michael Adler <mad1@tapil.com> To: "Crist J. Clark" <cjc@FreeBSD.ORG> Cc: FreeBSD-gnats-submit@FreeBSD.ORG Subject: Re: bin/39849: /sbin/restore fails to overwrite files with schg flag set Date: Thu, 27 Jun 2002 09:04:13 -0400 At 03:15 AM 6/27/2002, Crist J. Clark wrote: >On Tue, Jun 25, 2002 at 01:24:31PM -0400, Michael C. Adler wrote: >[snip] > > > Incremental restore fails to overwrite an older file that has a flag > > set making the file immutable. > >I really think this is a feature and not a bug. However, I can see >where one might want this. I think the right way would be to have a >command line switch which enables this [su]chg-flag clobbering, and >leave the default as-is. I agree it is debatable. It seems to me that restore is a special case. Its goal is to produce a target identical to the source. Given that the source changed, I thought the target should as well. It could easily be put on a switch or perhaps it should be turned on with the -r switch. >Note that there are other, tougher issues when doing restores on an >existing filesystem when names collide (e.g. does restore(8) >over-write an existing directory with a plain file from backup?). >Handling this issue by running a, > > # chflags -R 0 /filesystem/path > >Before a restore(8) is fairly trivial. Of course this might not do what you want. Does an incremental dump have all the flags for all files in the target during restore -r? If not, the target files may lose their flags. -Michael To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200206271310.g5RDA3Rx038996>