]> git.ipfire.org Git - thirdparty/man-pages.git/commitdiff
fcntl.2: srcfix: start new sentences on new lines; rewrap source lines
authorMichael Kerrisk <mtk.manpages@gmail.com>
Thu, 8 Jan 2015 05:54:37 +0000 (06:54 +0100)
committerMichael Kerrisk <mtk.manpages@gmail.com>
Mon, 19 Jan 2015 09:35:32 +0000 (10:35 +0100)
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
man2/fcntl.2

index 652d7e093312ff4acf945fc438216f1689e07654..d3768429f35cea4f70e044e34c28d02c73b16539 100644 (file)
@@ -1300,19 +1300,25 @@ of buffer space currently used to store data produces the error
 .BR F_GETPIPE_SZ " (\fIvoid\fP; since Linux 2.6.35)"
 Return (as the function result) the capacity of the pipe referred to by
 .IR fd .
+.\"
 .SS File Sealing
-File seals limit the set of allowed operations on a given file. For each
-seal that is set on a file, a specific set of operations will fail with
+File seals limit the set of allowed operations on a given file.
+For each seal that is set on a file,
+a specific set of operations will fail with
 .B EPERM
-on this file from now on. The file is said to be sealed. The default set of
-seals depends on the type of the underlying file and filesystem. Currently, only
-shmem supports sealing. On other filesystems, all
+on this file from now on.
+The file is said to be sealed.
+The default set of seals depends on the type of the underlying
+file and filesystem.
+Currently, only shmem supports sealing.
+On other filesystems, all
 .BR fcntl (2)
 operations that operate on seals will return
 .BR EINVAL .
-Seals are a property of an inode. Thus, all open files on an inode share the
-same set of seals. Furthermore, seals can never be removed, only added. If a
-seal is set, it is guaranteed to be enforced immediately.
+Seals are a property of an inode.
+Thus, all open files on an inode share the same set of seals.
+Furthermore, seals can never be removed, only added.
+If a seal is set, it is guaranteed to be enforced immediately.
 The following set of seals is available so far:
 .RS
 .TP
@@ -1323,14 +1329,14 @@ with
 .B F_ADD_SEALS
 will fail with
 .BR EPERM .
-Therefore, this seal prevents any modifications to the set of seals itself. If
-the initial set of seals of a file includes
+Therefore, this seal prevents any modifications to the set of seals itself.
+If the initial set of seals of a file includes
 .BR F_SEAL_SEAL ,
 then this effectively causes the set of seals to be constant and locked.
 .TP
 .BR F_SEAL_SHRINK
-If this seal is set, the file in question cannot be reduced in size. This
-affects
+If this seal is set, the file in question cannot be reduced in size.
+This affects
 .BR open (2)
 with the
 .B O_TRUNC
@@ -1338,12 +1344,12 @@ flag and
 .BR ftruncate (2).
 They will fail with
 .B EPERM
-if you try to shrink the file in question. Increasing the file size is still
-possible.
+if you try to shrink the file in question.
+Increasing the file size is still possible.
 .TP
 .BR F_SEAL_GROW
-If this seal is set, the size of the file in question cannot be increased. This
-affects
+If this seal is set, the size of the file in question cannot be increased.
+This affects
 .BR write (2)
 if you write across size boundaries,
 .BR ftruncate (2)
@@ -1351,23 +1357,25 @@ and
 .BR fallocate (2).
 These calls will fail with
 .B EPERM
-if you use them to increase the file size or write beyond size boundaries. If
-you keep the size or shrink it, those calls still work as expected.
+if you use them to increase the file size or write beyond size boundaries.
+If you keep the size or shrink it, those calls still work as expected.
 .TP
 .BR F_SEAL_WRITE
-If this seal is set, you cannot modify data contents of the file. Note that
-shrinking or growing the size of the file is still possible and allowed. Thus,
-this seal is normally used in combination with one of the other seals. This seal
-affects
+If this seal is set, you cannot modify data contents of the file.
+Note that shrinking or growing the size of the file is
+still possible and allowed.
+Thus, this seal is normally used in combination with one of the other seals.
+This seal affects
 .BR write (2)
 and
 .BR fallocate (2)
 (only in combination with the
 .B FALLOC_FL_PUNCH_HOLE
-flag). Those calls will fail with
+flag).
+Those calls will fail with
 .B EPERM
-if this seal is set. Furthermore, trying to create new shared, writable
-memory-mappings via
+if this seal is set.
+Furthermore, trying to create new shared, writable memory-mappings via
 .BR mmap (2)
 will also fail with
 .BR EPERM .
@@ -1379,8 +1387,9 @@ with
 .B F_ADD_SEALS
 will fail with
 .B EBUSY
-if any writable, shared mapping exists. You have to unmap
-those before you can add this seal. Furthermore, if there are any asynchronous
+if any writable, shared mapping exists.
+You have to unmap those before you can add this seal.
+Furthermore, if there are any asynchronous
 I/O operations pending on the file, all outstanding writes will be discarded.
 .RE
 .TP
@@ -1389,8 +1398,9 @@ Add the seals given in
 .I arg
 to the set of seals of the inode pointed to by the file-descriptor
 .IR fd .
-Seals cannot be removed again. Once this call succeeds, the seals are enforced
-by the kernel immediately. If the current set of seals includes
+Seals cannot be removed again.
+Once this call succeeds, the seals are enforced by the kernel immediately.
+If the current set of seals includes
 .B F_SEAL_SEAL
 then this call will be rejected with
 .BR EPERM .
@@ -1399,11 +1409,11 @@ Adding a seal that is already set is a no-op, in case
 is not set already.
 .TP
 .BR F_GET_SEALS " (\fIvoid\fP; since Linux TBD)"
-Return (as the function result) the current set of seals of the inode referred
-to by
+Return (as the function result) the current set of seals
+of the inode referred to by
 .IR fd .
-If no seals are set, 0 is returned. If the file does not support sealing, -1 is
-returned and
+If no seals are set, 0 is returned.
+If the file does not support sealing, -1 is returned and
 .I errno
 is set to
 .BR EINVAL .