* File name is not persisted if opened with O_SYNC and O_TRUNC flags
@ 2026-02-12 11:51 Vyacheslav Kovalevsky
2026-02-13 7:33 ` Christoph Hellwig
0 siblings, 1 reply; 3+ messages in thread
From: Vyacheslav Kovalevsky @ 2026-02-12 11:51 UTC (permalink / raw)
To: viro, brauner; +Cc: linux-fsdevel, linux-kernel, linux-btrfs, linux-ext4
Detailed description
====================
Hello, there seems to be an issue with O_SYNC flag when used together
with O_TRUNC on various file systems.
Opening a file with O_SYNC (or using fsync(fd)) should persist directory
entry.
However, if O_SYNC is used together with O_TRUNC the file will be
missing if system crashes.
According to POSIX this is OK, but most file systems provide stronger
guarantees (would be actually nice to have a more recent documentation
on this behavior).
This happens on Btrfs, ext4, XFS, F2FS and likely other file systems.
System info
===========
Linux version 6.19-rc7, also tested on 6.17
How to reproduce
================
```
#include <errno.h>
#include <fcntl.h>
#include <stdio.h>
#include <string.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <unistd.h>
int main() {
int status;
status = creat("file", S_IRWXU | S_IRWXG | S_IROTH | S_IXOTH);
printf("CREAT: %d\n", status);
close(status);
status = open("file", O_RDWR | O_TRUNC | O_SYNC);
printf("OPEN: %d\n", status);
}
// after the crash `file` is missing
```
Steps:
1. Create and mount new file system in default configuration.
2. Change directory to root of the file system and run the compiled test.
3. Cause hard system crash (e.g. QEMU `system_reset` command).
4. Remount file system after crash.
5. Observe that file is missing.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: File name is not persisted if opened with O_SYNC and O_TRUNC flags
2026-02-12 11:51 File name is not persisted if opened with O_SYNC and O_TRUNC flags Vyacheslav Kovalevsky
@ 2026-02-13 7:33 ` Christoph Hellwig
2026-02-13 10:25 ` Vyacheslav Kovalevsky
0 siblings, 1 reply; 3+ messages in thread
From: Christoph Hellwig @ 2026-02-13 7:33 UTC (permalink / raw)
To: Vyacheslav Kovalevsky
Cc: viro, brauner, linux-fsdevel, linux-kernel, linux-btrfs,
linux-ext4
On Thu, Feb 12, 2026 at 02:51:47PM +0300, Vyacheslav Kovalevsky wrote:
> Detailed description
> ====================
>
> Hello, there seems to be an issue with O_SYNC flag when used together with
> O_TRUNC on various file systems.
> Opening a file with O_SYNC (or using fsync(fd)) should persist directory
> entry.
No, it should not. I'm not sure who hallucinated, but O_SYNC has always
always applied to persistency semantics after writes and nothing else.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: File name is not persisted if opened with O_SYNC and O_TRUNC flags
2026-02-13 7:33 ` Christoph Hellwig
@ 2026-02-13 10:25 ` Vyacheslav Kovalevsky
0 siblings, 0 replies; 3+ messages in thread
From: Vyacheslav Kovalevsky @ 2026-02-13 10:25 UTC (permalink / raw)
To: Christoph Hellwig
Cc: viro, brauner, linux-fsdevel, linux-kernel, linux-btrfs,
linux-ext4
On 13/02/2026 10:33, Christoph Hellwig wrote:
> On Thu, Feb 12, 2026 at 02:51:47PM +0300, Vyacheslav Kovalevsky wrote:
>> Detailed description ==================== Hello, there seems to be an
>> issue with O_SYNC flag when used together with O_TRUNC on various
>> file systems. Opening a file with O_SYNC (or using fsync(fd)) should
>> persist directory entry.
> No, it should not. I'm not sure who hallucinated, but O_SYNC has
> always always applied to persistency semantics after writes and
> nothing else.
You are right, opening file with O_SYNC does not persist anything and
ftruncate or O_TRUNC do not count as write I/O it seems. Also found an
error related to these assumptions in our testing tool. Thanks.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2026-02-13 10:25 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-02-12 11:51 File name is not persisted if opened with O_SYNC and O_TRUNC flags Vyacheslav Kovalevsky
2026-02-13 7:33 ` Christoph Hellwig
2026-02-13 10:25 ` Vyacheslav Kovalevsky
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox