Subject: Re: bugs and/or misfeatures in namei changes
To: None <current-users@NetBSD.ORG>
From: Rick Byers <email@example.com>
Date: 05/12/1997 16:34:58
I've used the same cp trick - assuming it would fail if the target
directory didn't exist (when I'm too lazy to check first). I think there
is no question that this method is "better", but it's certainly not worth
sacrificing POSIX compliency.
I don't think anyone has mentioned the idea of introducing an option. It
won't be the first instance that a "POSIX_MISTAKE" option has been
introduced. It could either be a compile time option in namei,
and/or a flag for cp. If a flag was added to cp which would verify the
target directory existed before creating a regular file - then individual
users could decide which behaviour of cp they want. I admit adding an
option to cp doesn't "fix" the problem, but in conjunction with a compile
time option in namei (which should default to POSIX behaviour) - it should
make everyone happy.
Anyway, I'd be disgusted to see a piece of software that checks for an
existing file with a slash at the end.
On Sun, 11 May 1997, John F. Woods wrote:
> > Why is the POSIX way necessarily Right? If POSIX requires this bizarre
> > behavior of cp, as described by several people, then I think POSIX is
> > broken badly enough that conformance to this aspect of it is not worth
> > the damage it requires.
> Speaking as the original complainer here, to repeat a point that has been made
> dozens of times: POSIX compliance makes it possible for implementors to write
> programs without caring what OS they're writing for; it makes it possible for
> us to benefit *instantly* from the work of a large number of people as long
> as they write their applications to rely on the promises POSIX makes. This
> is crucial for commercial software ("better but nonstandard" just doesn't
> cut it with commercial developers, trust me on this), and helpful even for
> publically-available software (since you don't have to go through it and
> port it to NetBSD).
> "We're almost standard but better in small and annoying ways" is why UNIX
> fragmented to the point where MS-DOS was able to conquer the world. You
> can always "repair" NetBSD in the privacy of your own machine room, of course;
> just don't be surprised when you start having trouble porting software to it
> because you've "repaired" things that applications writers don't think are
> At least System V is effectively dead, and won't be injuring future standards.
>  Look how far "better but nonstandard" got UNOS...
Rick Byers Internet Access Worldwide
firstname.lastname@example.org System Administrator
Welland, Ontario, Canada (905)714-1400