GLib 2.20.0 is now available for download at:
ftp://ftp.gtk.org/pub/glib/2.20
http://download.gnome.org/sources/glib/2.20
glib-2.20.0.tar.bz2 md5sum: 05188e560dbd8bddd568e24ce10dd003
glib-2.20.0.tar.gzmd5sum: 81a6151c9591378af31d78e7eb304e71
GLib is the low-level core library that forms
GTK+ 2.16.0 is now available for download at:
http://download.gnome.org/sources/gtk+/2.16/
ftp://ftp.gtk.org/pub/gtk/2.16/
gtk+-2.16.0.tar.bz2 md5sum: 139528802794287427fd4d18875b5cf5
gtk+-2.16.0.tar.gzmd5sum: 2e926e526850d9cf62883c6d909b4351
Release notes are available at:
On Thu, 2009-03-12 at 21:27 +, Michael Meeks wrote:
On Thu, 2009-03-12 at 21:11 +0100, Alexander Larsson wrote:
With all the recent yahoo about ext4 data loss and fsync I felt I had to
look at glib and make sure we're doing this right.
Hmm; is this not just a database guy ? ;-)
Hi Alex,
On Fri, 2009-03-13 at 08:38 +0100, Alexander Larsson wrote:
If you want to you can make all i/o sync by mounting it as such. But
thats of course really slow. Generally the gio file write operations are
used for saving files, and people sort of expect that when save returns
the file
Alexander Larsson wrote:
Attached is a patch that makes sure we fsync before closing in the gio
file saving code and in g_file_set_contents().
Wouldn't fdatasync be sufficient in most case ?
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
On Fri, 2009-03-13 at 11:37 +0100, Steve Frécinaux wrote:
Alexander Larsson wrote:
Attached is a patch that makes sure we fsync before closing in the gio
file saving code and in g_file_set_contents().
Wouldn't fdatasync be sufficient in most case ?
In practical gio use there really is no
Am Freitag, den 13.03.2009, 12:18 +0100 schrieb Sven Neumann:
Hi,
On Fri, 2009-03-13 at 08:38 +0100, Alexander Larsson wrote:
If you want to you can make all i/o sync by mounting it as such. But
thats of course really slow. Generally the gio file write operations are
used for saving
I think I am in line with what Michael is saying here: there is a
non-trivial risk that littering fsync all over the place will badly
affect existing systems.
The ext4 attitude is interesting, btw. They are saying that
POSIX allows this behaviour so it's your problem. But when
the gcc people
GLib 2.20.0 is now available for download at:
ftp://ftp.gtk.org/pub/glib/2.20
http://download.gnome.org/sources/glib/2.20
glib-2.20.0.tar.bz2 md5sum: 05188e560dbd8bddd568e24ce10dd003
glib-2.20.0.tar.gzmd5sum: 81a6151c9591378af31d78e7eb304e71
GLib is the low-level core library that forms
Hi,
On Fri, 2009-03-13 at 14:11 +0100, Mathias Hasselmann wrote:
I think you don't understand the problem.
That might very well be the case. I had a look at the presentation that
Alex linked to in the initial post in this thread. But I would have
preferred a document that doesn't look at the
On Fri, Mar 13, 2009 at 12:37 PM, Steve Frécinaux nudr...@gmail.com wrote:
Alexander Larsson wrote:
Attached is a patch that makes sure we fsync before closing in the gio
file saving code and in g_file_set_contents().
Wouldn't fdatasync be sufficient in most case ?
Narrowed reply: not all
On 03/13/2009 09:15 AM, Morten Welinder wrote:
I think I am in line with what Michael is saying here: there is a
non-trivial risk that littering fsync all over the place will badly
affect existing systems.
The ext4 attitude is interesting, btw. They are saying that
POSIX allows this behaviour
GTK+ 2.16.0 is now available for download at:
http://download.gnome.org/sources/gtk+/2.16/
ftp://ftp.gtk.org/pub/gtk/2.16/
gtk+-2.16.0.tar.bz2 md5sum: 139528802794287427fd4d18875b5cf5
gtk+-2.16.0.tar.gzmd5sum: 2e926e526850d9cf62883c6d909b4351
Release notes are available at:
On Fri, 2009-03-13 at 14:35 +0100, Sven Neumann wrote:
Hi,
On Fri, 2009-03-13 at 14:11 +0100, Mathias Hasselmann wrote:
I think you don't understand the problem.
That might very well be the case. I had a look at the presentation that
Alex linked to in the initial post in this thread.
Sven Neumann wrote:
It seems wrong to work around broken file-systems on the application
level. That only takes away pressure from the file-system developers to
address the problem properly.
How is the file system broken? Read the man page for write(). If you
want to guarantee that file
On Fri, 2009-03-13 at 11:11 -0700, Brian J. Tarricone wrote:
Sven Neumann wrote:
It seems wrong to work around broken file-systems on the application
level. That only takes away pressure from the file-system developers to
address the problem properly.
How is the file system broken?
On Fri, 2009-03-13 at 18:45 +0100, Alexander Larsson wrote:
One compromise we could make it to only fsync in the case we're actually
overwriting an existing file. This would mean that we don't risk loosing
both the old and the new version of the file, you only lose new files.
This case is far
On Fri, 2009-03-13 at 09:15 -0400, Morten Welinder wrote:
F*** POSIX allows this! A program that does open-write-close-
rename should not be left with an empty file in case something
goes wrong. The old file, or the new file. Anything else is insane
and by extension the kernel developers
On 03/13/2009 05:16 PM, Alexander Larsson wrote:
On Fri, 2009-03-13 at 15:05 -0600, Federico Mena Quintero wrote:
On Fri, 2009-03-13 at 09:15 -0400, Morten Welinder wrote:
F*** POSIX allows this! A program that does open-write-close-
rename should not be left with an empty file in case
Alexander Larsson wrote:
On Fri, 2009-03-13 at 11:11 -0700, Brian J. Tarricone wrote:
Sven Neumann wrote:
It seems wrong to work around broken file-systems on the application
level. That only takes away pressure from the file-system developers to
address the problem properly.
How is the
Behdad Esfahbod wrote:
Its well explained in the various discussions about this. Essentially,
the metadata for the rename is written to disk, but the data in the file
is not (yet, due to delayed allocation) and then the system crashes. On
fsck we discover the file is broken (no data) and set the
Mark Mielke wrote:
Putting fsync() on close() is a hack.
Hmm - Looking at the patch, I don't see it doing fsync() on close() - I
should have read from the beginning instead of reacting to the one
person calling the file system semantics broken. :-)
Definitely - any file system operations
On Fri, 2009-03-13 at 22:16 +0100, Alexander Larsson wrote:
Its well explained in the various discussions about this. Essentially,
the metadata for the rename is written to disk, but the data in the file
is not (yet, due to delayed allocation) and then the system crashes. On
fsck we discover
On Fri, Mar 13, 2009 at 06:20:57PM -0600, Federico Mena Quintero wrote:
My point is that the kernel could perfectly well ensure that
metadata operations that depend on data operations will not be
reordered.
I think that's how ext3 works by default (data=ordered mount option).
GLib 2.20.0 is now available for download at:
ftp://ftp.gtk.org/pub/glib/2.20
http://download.gnome.org/sources/glib/2.20
glib-2.20.0.tar.bz2 md5sum: 05188e560dbd8bddd568e24ce10dd003
glib-2.20.0.tar.gzmd5sum: 81a6151c9591378af31d78e7eb304e71
GLib is the low-level core library that forms
GTK+ 2.16.0 is now available for download at:
http://download.gnome.org/sources/gtk+/2.16/
ftp://ftp.gtk.org/pub/gtk/2.16/
gtk+-2.16.0.tar.bz2 md5sum: 139528802794287427fd4d18875b5cf5
gtk+-2.16.0.tar.gzmd5sum: 2e926e526850d9cf62883c6d909b4351
Release notes are available at:
26 matches
Mail list logo
