How useful should copy_file_range() be?

Posted Feb 18, 2021 16:41 UTC (Thu) by zuzzurro (subscriber, #61118)
In reply to: How useful should copy_file_range() be? by zuzzurro
Parent article: How useful should copy_file_range() be?

What if these "non seekable" files were simply flagged as named pipes?

How useful should copy_file_range() be?

Posted Feb 18, 2021 18:38 UTC (Thu) by smurf (subscriber, #17840) [Link] (5 responses)

Some of these /proc files are quasi-seekable IIRC, in that they return an offset which indicates your read position but which does not correspond to the character count from beginning-of-file to wherever you were when you called lseek(fd,SEEK_CUR).

How useful should copy_file_range() be?

Posted Feb 20, 2021 12:16 UTC (Sat) by jengelh (guest, #33263) [Link] (4 responses)

Looking at the POSIX description for the lseek(2) POSIX-C function, it is required to operate in terms of bytes.

I am not getting that with the /proc/self/sched file (uses `seq_lseek`, which operates in terms of records). Is sys_llseek *meant* to be POSIX-compatible?
If yes, it's a kernel bug.
If no, then it's a libc bug because it failed to provide/emulate POSIX semantics on top of an (unposixy) kernel interface.
So, which is it, where should I file a bug?

How useful should copy_file_range() be?

Posted Feb 20, 2021 14:45 UTC (Sat) by smurf (subscriber, #17840) [Link]

Those fake kernel files don't have POSIX semantics, period. Their reported size doesn't correspond to the number of readable bytes, if they're writeable you can't just write '1' and then '23' when you intend to write '123', and so on.

So the bug is on the user. If you treat these things like ordinary files and expect all the posicky corner cases to work "correctly", you're SOL. These files will never have POSIX semantics. No, you can't use libc to emulate it. Deal.

Yes there should be a way to ask the kernel whether a file conforms to 100% posix. Well, we don't have that. Deal.

One possible workaround is to check the file size. If it's smaller than pagesize*4 or so then it's probably cheaper to copy its data the old-fashioned way anyway.

How useful should copy_file_range() be?

Posted Feb 20, 2021 17:01 UTC (Sat) by markh (subscriber, #33984) [Link] (2 responses)

The bug is that the kernel is reporting it as a regular file (in st_mode), but then does not satisfy the requirements for regular files. If the kernel does not want to satisfy those requirements, all that is needed is to report it as a type of file that does not have the requirements that it cannot satisfy. It is not reasonable to expect userspace programs to somehow guess that a file reported as a regular file cannot be relied upon to behave as such.

How useful should copy_file_range() be?

Posted Feb 23, 2021 19:02 UTC (Tue) by jsmith45 (guest, #125263) [Link] (1 responses)

Very true. The problem is that there is almost certainly a bunch of programs out there that will break if the file types of /proc pseudofiles changes to be anything but a normal file.

How useful should copy_file_range() be?

Posted Feb 25, 2021 11:12 UTC (Thu) by zuzzurro (subscriber, #61118) [Link]

Given the amount of confusion that is visible in the thread where kernel programmers are trying to find the best way to fix this I find it sad that people have tried to just throw the issue off to the userland.