From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Tue, 25 Sep 2018 19:35:11 +0200 From: Adam Borowski To: "Theodore Y. Ts'o" , Jeff Layton , Alan Cox , =?utf-8?B?54Sm5pmT5Yas?= , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Rogier Wolff Subject: Re: POSIX violation by writeback error Message-ID: <20180925173510.273hshp4iapd6dcd@angband.pl> References: <486f6105fd4076c1af67dae7fdfe6826019f7ff4.camel@redhat.com> <20180925003044.239531c7@alans-desktop> <0662a4c5d2e164d651a6a116d06da380f317100f.camel@redhat.com> <20180925154627.GC2933@thunk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20180925154627.GC2933@thunk.org> Sender: linux-kernel-owner@vger.kernel.org List-ID: On Tue, Sep 25, 2018 at 11:46:27AM -0400, Theodore Y. Ts'o wrote: > P.S. One thought: it might be cool if there was some way for > userspace applications to mark files with "nuke if not closed" flag, > such that if the system crashes, the file systems would automatically > unlink the file after a reboot or if the process was killed or exits > without an explicit close(2). For networked/remote file systems that > supported this flag, after the client comes back up after a reboot, it > could notify the server that all files created previously from that > client should be unlinked. > > Unlike O_TMPFILE, this would require file system changes to support, > so maybe it's not worth having something which automatically cleans up > files that were in the middle of being written at the time of a system > crash. Isn't this what the snippet for O_TMPFILE in "man 2 open" does?: char path[PATH_MAX]; fd = open("/path/to/dir", O_TMPFILE | O_RDWR, S_IRUSR | S_IWUSR); /* File I/O on 'fd'... */ snprintf(path, PATH_MAX, "/proc/self/fd/%d", fd); linkat(AT_FDCWD, path, AT_FDCWD, "/path/for/file", AT_SYMLINK_FOLLOW); Meow! -- ⢀⣴⠾⠻⢶⣦⠀ 10 people enter a bar: ⣾⠁⢰⠒⠀⣿⡁ • 1 who understands binary, ⢿⡄⠘⠷⠚⠋⠀ • 1 who doesn't, ⠈⠳⣄⠀⠀⠀⠀ • and E who prefer to write it as hex.