Date: Tue, 13 Jun 1995 18:21:40 +0200 (MET DST) From: J Wunsch <j@uriah.heep.sax.de> To: ruplit@fitipc31.tu-graz.ac.at (Michael Ruplitsch) Cc: freebsd-bugs@FreeBSD.org (FreeBSD bugs list) Subject: Re: dump having problems with remote tape drive Message-ID: <199506131621.SAA07714@uriah.heep.sax.de> In-Reply-To: <Pine.BSD.3.91.950613090104.20101A-100000@fitipc31.tu-graz.ac.at> from "Michael Ruplitsch" at Jun 13, 95 09:09:15 am
next in thread | previous in thread | raw e-mail | index | archive | help
As Michael Ruplitsch wrote: > > > Is there any reason why a tape driver should not allow an O_RDWR > > access where it does allow O_WRONLY? > Hmm, I don't think so. But on the other hand: what does dump need the > read permission for? Ok, so it's not a fatal bug, but perhaps worth to be fixed anyway. > > Anyway, i found another bogon while i've been looking at this: dump > > doesn't use an absolute path (/etc/rmt) as it ought to be; instead it > > thinks it should rely on "rmt" only. > As far as I know rmt does not live in /etc anymore. It's a link to > /usr/sbin/rmt which is kept for reasons of backward compatibility. *Our* rmt program does not live in /etc, yes. Anyway, since it's a remote protocol, we cannot rely on any particular location for any particular system. The only convention for the location is /etc (as it used to be all the time), hence every system usually keeps the symlink there. The salomonic decision of the 4.4BSD designers to let rdump just ask for "rmt" instead of any particular path is IMVHO a bad bug. It's now relying on some user's login path setting. (Btw., GNU tar, also using the rmt protocol, made it obvious that we actually need the symlink, that's why it is there now.) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199506131621.SAA07714>