We didn't actually do any real-world testing of this, and
unsurprisingly it turns out to break in at least one widely-used
configuration (Fedora 19 x86_64, ext4 on LVM).
This reverts commit 9d0c17b50102267a5029b58b1f44efbad82d8f03.
https://bugzilla.gnome.org/show_bug.cgi?id=701560
ext3 and ext4 (for quite some time) with default mount options don't
need fsync() to ensure safety of replace-by-rename. Stop doing that for
these filesystems.
Note: this patch also impacts ext2, which is probably not safe, but I
don't know of any way to check ext2. vs the others because they all have
the same magic numbers (short of opening /proc/mount).
This patch assumes that if BTRFS_SUPER_MAGIC is defined then so will be
EXT3_SUPER_MAGIC.
https://bugzilla.gnome.org/show_bug.cgi?id=701560
Use a normal write() system call instead of fdopen() and fwrite().
This will definitely work on UNIX system and should work on Windows as
well...
As an added bonus, we can use g_close() now as well.
https://bugzilla.gnome.org/show_bug.cgi?id=701560
g_file_set_contents() sets a GError in the event of various failures
that count occur. It uses g_filename_display_name() in order to get the
filename to include in the messages.
Factor out the error handling to make it easier to allocate the display
name only when we need it (instead of allocating it every time).
https://bugzilla.gnome.org/show_bug.cgi?id=701560
Extents-based filesystems like knowing in advance how much data will be
written to a file in order to prevent fragmentation. If we have it, use
posix_fallocate() before writing data in g_file_set_contents().
https://bugzilla.gnome.org/show_bug.cgi?id=701560
Back in the far-off twentieth century, it was normal on unix
workstations for U+0060 GRAVE ACCENT to be drawn as "‛" and for U+0027
APOSTROPHE to be drawn as "’". This led to the convention of using
them as poor-man's ‛smart quotes’ in ASCII-only text.
However, "'" is now universally drawn as a vertical line, and "`" at a
45-degree angle, making them an `odd couple' when used together.
Unfortunately, there are lots of very old strings in glib, and also
lots of new strings in which people have kept up the old tradition,
perhaps entirely unaware that it used to not look stupid.
Fix this by just using 'dumb quotes' everywhere.
https://bugzilla.gnome.org/show_bug.cgi?id=700746
open() is probably defined varargs. Casting a varargs function to an
equivalent non-varargs type and then calling it is undefined, but
gfileutils.c was doing exactly that.
Add some non-varargs wrappers to avoid the problem.
Problem reported by John Spencer.
https://bugzilla.gnome.org/show_bug.cgi?id=687600
This is a regression introduced by:
commit 6ac8e6108cf15884e28fe1ecd3042dfce0e11dfd
Author: Matthias Clasen <mclasen@redhat.com>
Date: Tue Jun 14 10:12:46 2011 -0400
Don't leak resources in error cases
At the same time, also add g_mkdtemp_full and g_dir_make_tmp
variants. The patch also unifies the unique-name-generating
code for all variants of mkstemp and mkdtemp and adds tests
for the new functions.
Based on patches by Paolo Bonzini,
http://bugzilla.gnome.org/show_bug.cgi?id=118563
The long format that displays the exact number of bytes with separators
(ie: "123,456,789 bytes") uses the ' format modifier, which is
unsupported on Windows. Disable that for now, until we come up with a
better solution.
David requested that I change the order of the flags.
Also, assign numerical values to the flags in the usual way. This
wasn't a bug yet, but only by chance.
This commit changes GLib size units policy. We now prefer SI units and
allow for use of proper IEC units where desired.
g_format_size_for_display() which incorrectly mixed IEC units with SI
suffixes is left unmodified, but has been deprecated.
g_format_size() has been introduced which uses SI units and suffixes.
g_format_size_full() has also been added which takes a flags argument to
allow for use of IEC units (with correct suffixes). It also allows for
a "long format" output which includes the total number of bytes. For
example: "238.5 MB (238,472,938 bytes)".
Rename the size constants from KILOBYTE to KIBIBYTE (etc.) since that's
what they really are.
This is a strictly internal change with no externally-visible effect in
terms of API or functionality.
For g_file_set_contents() we fsync() before renaming the file over the
original in order to ensure that we don't end up with an invalid file.
btrfs provides this guarantee for us without the fsync() so skip it
there.
This function exposes more variables than g_mkstemp() and therefor
allows more flexibility when creating temporary files.
The intended use is gio's code for g_file_replace() (see next patch)
This means we don't sync in the case where we created an (empty)
temp file and now replace it with the data.
This fixes (among other things) the performance of trashing files.
