From owner-freebsd-bugs Tue Jul 9 03:17:46 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id DAA25640 for bugs-outgoing; Tue, 9 Jul 1996 03:17:46 -0700 (PDT) Received: from freebsd.gaffaneys.com ([134.129.252.29]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id DAA25630 for ; Tue, 9 Jul 1996 03:17:42 -0700 (PDT) Received: (from zach@localhost) by freebsd.gaffaneys.com (8.6.12/8.6.12) id FAA05263; Tue, 9 Jul 1996 05:18:05 -0500 To: Bruce Evans Cc: freebsd-bugs@freefall.freebsd.org Subject: Re: bin/1375: Extraneous warning from mv(1) References: <199607080830.BAA16658@freefall.freebsd.org> From: Zach Heilig Date: 09 Jul 1996 05:18:04 -0500 In-Reply-To: Bruce Evans's message of Mon, 8 Jul 1996 01:30:07 -0700 (PDT) Message-ID: <8720ilafxf.fsf@freebsd.gaffaneys.com> Lines: 40 X-Mailer: Gnus v5.2.32/Emacs 19.31 Sender: owner-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Bruce Evans writes: > >According to mv(1), moving a file across filesystems is equivalent to > >calling cp -pRP, surrounded by calls to rm(1). According to cp(1), > >when the -p option is used, no error message should be displayed if > >the user and group ID of the file cannot be preserved. > This is probably a bug in mv.1. mv should and does try harder than > cp to preserve attributes. But why should I, as a user, care.. as long as the setuid/setgid bits and the group write bit are not set, it doesn't really make that much difference. In fact, the user should not be notified of errors that are not of significance, as they might then ignore significant ones, for example: mv: ./bar: set owner/group: Operation not permitted looks very similar to: mv: ./bar: set mode: Operation not permitted when you just know that any messages from mv(1) don't mean anything to you. See my problem report for what currently happens when you see a message like the second (it is very bad). Who knows what other bugs are out there that users might notice if they weren't ignoring extraneous output. > >mv(1) behaves as expected if the file and its destination directory > >are on the same filesystem, or if a directory is moved across a > >filesystem instead of a file. > The latter is a bug in mv. It really does use cp -pRP in this case, > but cp -pRP is inadequate. It snaps links, doesn't preserve preservable > directory timestamps, and does the wrong thing for `mv dir existing-dir'. -- Zach Heilig (zach@blizzard.gaffaneys.com) Support bacteria -- it's the only culture some people have! ALL unsolicited >commercial< email is subject to a $100 proof-reading fee.