On Wed, Dec 05, 2001 at 05:10:49PM +1000, Greg Black wrote:
> "Crist J . Clark" wrote:
>
> | On Wed, Dec 05, 2001 at 06:02:49AM +1000, Greg Black wrote:
> | > Matthew Dillon wrote:
> | >
> | > | :In message <[EMAIL PROTECTED]>, Bernd Walter writes:
> | > | :>> Is there any reason we don't want to truncate the file? Does O_TRUNC
> | > | :>> not work well of the file is a tape device or something?
> | > | :>
> | > | :>I don't expect O_TRUNK to work on devices such tapes and disks.
> | > | :
> | > | :Well, it won't achieve anything on tapes or disk devices, but it
> | > | :should be completely harmless to add the O_TRUNC flag. The current
> | > | :behaviour is likely to be unexpected and cause confusion so it
> | > | :might as well be changed. I'll commit this later unless someone
> | > | :can think of a good reason not to.
> | > | :
> | > | :Ian
> | > |
> | > | Woa! That sounds like a bad idea to me. If you want to do it right
> | > | then open(), fstat(), and only if the stat says it is a regular file
> | > | do you then ftruncate(). Passing O_TRUNC to a tape device may be ignored
> | > | by us, but it's not a valid flag to pass to a tape device and we shouldn't
> | > | do it.
> | >
> | > I haven't used any of them for a while, but there are certainly
> | > Unix systems that treat O_TRUNC as a signal to rewind a tape
> | > device before writing to it.
> |
> | So? Who cares? This is FreeBSD's dump(8) and FreeBSD's write(2). There
> | is no reason to worry about portability of FreeBSD's dump(8) in how
> | write(2) flags work. If our write(2) "does the right thing" with
> | O_TRUNC and tape devices, there is no reason not to let it do the
> | right thing on its own.
>
> That's a rather strange attitude. All I was suggesting that,
> from the once-respected POLA, it would be less surprising to
> people who might have experience of other systems if FreeBSD did
> not make its own arrangements without some good reason.
>From what Ian said elsewhere in this thread, the O_TRUNC already does
not "act strange" on a tape device. I don't see any new POLA issues if
adding O_TRUNC to the write call doesn't change how dump(8) has been
working on tapes for FreeBSD for these n years now. The only POLA
issue I see is the current behavior that "regular" files are _not_
truncated, which was the start of the thread and the issue in the PR.
> There's
> no need for responses like: "So? Who cares?" -- if there's some
> reason not to consider other people, by all means explain it;
> but be polite while you're at it.
I don't see who would care if FreeBSD's dump(8) might have some funny
reactions on UNIX-like systems where O_TRUNC has a different behavior
on tape devices. I don't think the Project is overly concerned about
porting FreeBSD's dump(8) to other OSes.
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/ | [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
