On Nov 03 2016, Nikolaus Rath <Nikolaus-BTH8mxji4b0@xxxxxxxxxxxxxxxx> wrote:
> On Nov 03 2016, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
>> On Wed, Nov 02, 2016 at 11:53:40PM +0100, Jose Lopes wrote:
>>> Syscall 'ftruncate' makes the 'file' struct available to filesystem
>>> handlers. This makes it possible, e.g., for filesystems, such as,
>>> FUSE, to access the file handle associated with the file descriptor
>>> that was passed to 'ftruncate'. In the specific case of FUSE, this
>>> also makes it possible for (userspace) FUSE-based filesystems to
>>> distinguish between calls to 'truncate' and 'ftruncate'.
>>
>> Why FUSE is such a precious snowflake that it needs to make that distinction,
>> unlike all other filesystems?
>
> FUSE filesystems are often used as an extra layer on top of another
> filesystem (that stores the actual data). If the user opens a file (in
> the fuse filesystem), deletes it, and then truncates it, FUSE currently
> cannot do the same operation in the underlying filesystem: it receives
> a truncate() call with the inode, but there is no syscall that allows
> truncation for an inode. If FUSE had access to the file handle, it can
> use that to store a file descriptor for the file on the underlying
> filesystem and use ftruncate.
In case it wasn't clear: for the case of ftruncate, fuse *does* have
access to the file handle so the problem does not arise. For the case of
fchmod, this is currently a problem (and the patch we're discussing
would fix it).
Best,
-Nikolaus
--
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
»Time flies like an arrow, fruit flies like a Banana.«
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
