Aneesh,
[...]
>> --- a/man2/open.2
>> +++ b/man2/open.2
>> @@ -428,6 +427,66 @@ For a discussion of the effect of
>> in conjunction with mandatory file locks and with file leases, see
>> .BR fcntl (2).
>> .TP
>> +.BR O_PATH " (since Linux 2.6.39)"
>> +.\" commit 1abf0c718f15a56a0a435588d1b104c7a37dc9bd
>> +Obtain a file descriptor that is used only for fetching file attributes.
>> +The file itself is not opened, and most file operations (e.g.,
>> +.BR read (2),
>> +.BR write (2))
>> +fail with the error
>> +.BR EBADF .
>> +The following operations
>> +.I can
>> +be performed on the resulting file descriptor:
>> +.RS
>> +.IP * 3
>> +Closing the file descriptor
>> +.RB ( close (2)).
>> +.\" FIXME Commit 1abf0c718f15a56a0a435588d1b104c7a37dc9bdcw
>> +.\" message says that closing the file descriptor does not affect
>> +.\" POSIX locks or dnotify.
>> +.\" However, my testing shows that it DOES affect dnotify (and inotify).
>> +.\" Does close() affect POSIX locks?
>> +.IP *
>
>
> IIUC what an O_PATH descritor doesn't do is to flush dnotify markers
>
> if (likely(!(filp->f_mode & FMODE_PATH))) {
> dnotify_flush(filp, id);
> locks_remove_posix(filp, id);
> }
>
> I don't know much about markers, but as per fsnotify_backend.h
>
> /*
> * a mark is simply an object attached to an in core inode which allows an
> * fsnotify listener to indicate they are either no longer interested in events
> * of a type matching mask or only interested in those events.
> *
> * these are flushed when an inode is evicted from core and may be flushed
> * when the inode is modified (as seen by fsnotify_access). Some fsnotify users
> * (such as dnotify) will flush these when the open fd is closed and not at
> * inode eviction or modification.
> */
> struct fsnotify_mark {
Unfortunately, I'm still none the wiser about what this means for
O_PATH file descriptors...
> It also doesn't remove posix locks. I tested this with a test prg
>
> struct flock flock;
> flock.l_type = F_WRLCK;
> flock.l_whence = SEEK_SET;
> flock.l_start = 0;
> flock.l_len = 0;
> fd = open(argv[1], O_RDWR);
> fcntl(fd, F_SETLKW, &flock);
> fd = open(argv[1], O_PATH);
> close(fd);
>
> The close doesn't result in lock release.
Okay -- I'll add mention of this to the O_PATH description.
Thanks,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface"; http://man7.org/tlpi/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
