Hi Michael,
On Wed, May 6, 2015 at 4:17 PM, Michael Kerrisk (man-pages)
<mtk.manpages@xxxxxxxxx> wrote:
> I did some editing of the text and added some details to come up with the
> following. Could you please check it over? I also have one question below.
> (I have also added some entries under ERRORS, but I've omitted them here.)
>
> RENAME_WHITEOUT (since Linux 3.18)
> This operation makes sense only for overlay/union
> filesystem implementations.
>
> Specifying RENAME_WHITEOUT creates a "whiteout" object
> at the source of the rename at the same time as per‐
> forming the rename. The whole operation is atomic, so
> that if the rename succeeds then the whiteout will
> also have been created.
>
> A "whiteout" is an object that has special meaning in
> union/overlay filesystem constructs. In these con‐
> structs, multiple layers exist and only the top one is
> ever modified. A whiteout on an upper layer will
> effectively hide a matching file in the lower layer,
> making it appear as if the file didn't exist.
>
> When a file that exists on the lower layer is renamed,
> the file is first copied up (if not already on the
> upper layer) and then renamed on the upper, read-write
> layer. At the same time, the source file needs to be
> "whiteouted". The whole operation needs to be done
>
> ???
> After "whitedout", I am tempted to add: "(so that the version of
> the source file in the lower layer is rendered invisible)".
> Is that a correct formulation, and is it helpful to add it?
Yes, that's correct, and helpful, I think.
>
> atomically.
>
> When not part of a union/overlay, the whiteout appears
> as a character device with a {0,0} device number.
>
> RENAME_WHITEOUT requires the same privileges as creat‐
> ing a device node (i.e., the CAP_MKNOD capability).
>
> RENAME_WHITEOUT can't be employed together with
> RENAME_EXCHANGE.
>
> RENAME_WHITEOUT requires support from the underlying
> filesystem. Among the filesystems that provide that
> support are shmem (since Linux 3.18), ext4 (since
> Linux 3.18), and XFS (since Linux 4.1).
Looks good to me.
Thanks,
Miklos
--
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
