On Fri, Oct 14, 2022 at 03:37:29PM +0200, Marco d'Itri wrote:
> On Oct 14, Vincent Lefevre <vinc...@vinc17.net> wrote:
>
> > > This is obviously convenient on Guillem's part, but we have to optimize
> > > systems by default for the general case and not just for dpkg -i.
> > This dpkg FAQ says that this is not beneficial for just dpkg,
> > but also "for any application in the system".
> [citation needed]
>
> I hope that you understand why at this point I cannot trust as is the
> opinions of the dpkg maintainer.
The dpkg FAQ is just wrong. It relates to controversy which is over a
dozen years old. For more information see, see Josef Sipek's blog
post from 2009, "O_PONIES & Other Assorted Wishes"
https://blahg.josefsipek.net/?p=364
The O_PONIES mention references an 2009 April Fool's patch:
https://lore.kernel.org/linux-fsdevel/20090401041843.gn19...@josefsipek.net/
Because buggy applications and clueless application programmers vastly
outnumbers file system maintainers, at the 2009 LSF/MM workshop, a
number of the major file system developers agreed on the following
workaround. If the application opens a pre-existing file with
O_TRUNC, or renames a newly created file on top of pre-existing file,
we will force the delayed allocation to be automatically resolved when
the file is closed (in the first case) or the rename (in the second
case). It does *not* force a file system commit. So if you crash
within 5 seconds of the close(2) or rename(2), you will still suffer
data loss.
HOWEVER, this was always the case for buggy applicatons that refused
to call fsync(2) who were relying on the old ext3 file system
semantics. It did not guarantee that things would work; it would just
*mostly* work, since *usually* you didn't crash within 5 seconds of
rewriting a file.
So no, we're not going to be making the default change to /etc/fstab.
NACK.
- Ted
