bug-tar
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-tar] opening files with O_NONBLOCK causes problems


From: Eric Blake
Subject: Re: [Bug-tar] opening files with O_NONBLOCK causes problems
Date: Fri, 06 Jan 2012 08:17:29 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0

On 01/06/2012 07:42 AM, Joerg Schilling wrote:
> The main problem in this context is that the behavior for O_NONBLOCK on 
> non-FIFO files is _unspecified_.

But the extent of that unspecification is _bounded_, per POSIX, as follows:

05578 Change Number: XSH/TC1/D3/0418 [141]
05579 On Page: 1380 Line: 45239 Section: open()
05580 In the DESCRIPTION section (for O_NONBLOCK), change from:
05581 Otherwise, the behavior of O_NONBLOCK is unspecified.
05582 to:
05583 Otherwise, the O_NONBLOCK flag shall not cause an error, but it is
05584 unspecified whether the file status flags will include the O_NONBLOCK
05585 flag.
05586 Rationale: Austin Group Defect Report(s) applied: 141.
05587 See http://austingroupbugs.net/view.php?id=141

That is, using O_NONBLOCK is _required_ to succeed on all file types,
where the _only_ thing that is unspecified is whether fcntl() can then
observe whether O_NONBLOCK was set, for fds that do not support
non-blocking operations.  POSIX also requires that if fcntl() can
observe O_NONBLOCK set and the flag makes a difference in how that fd
behaves, then that flag can be cleared, so in practice, this means that
ALL implementations (such as DMF) that provide non-blocking semantics on
files not specified by POSIX can be portably turned back to normal
operations with fcntl() (the POSIX wording also permits implementations
where, for fds where O_NONBLOCK has no effect, either the O_NONBLOCK
flag is never observed to be set on such an fd, or where it can be
observed to be set but cannot be cleared by fcntl, but either way, those
implementations do not matter because O_NONBLOCK has no effect on those
fds).

> The solution you are currently discussing is specific to the implementation 
> of 
> your HSM. Other software could have a behavior that would cause other 
> problems 
> in case you use the solution that works for your HSM.

No, the solution is generic to any implementation that complies with
POSIX, not just HSM.

-- 
Eric Blake   address@hidden    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]