GitLab

Apparently, `fsync()` doesn’t actually sync to the spinning disk on
macOS. You need an `fcntl()` for that.

See: https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man2/fsync.2.html

Spotted by Christoph Reiter in a comment on !369.
Signed-off-by: Philip Withnall <withnall@endlessm.com>

Signed-off-by: Philip Withnall <withnall@endlessm.com>

Signed-off-by: Philip Withnall <withnall@endlessm.com>

Signed-off-by: Philip Withnall <withnall@endlessm.com>

Where applicable. Where the current use of `g_file_set_contents()` seems
the most appropriate, leave that in place.
Signed-off-by: Philip Withnall <withnall@endlessm.com>

Helps: #1302

This is used when creating the temporary file, or new file from scratch.

I wondered about also allowing the file owner and group to be set, but
that’s not as generally applicable — if your process is operating across
multiple user IDs then it likely has some fairly OS-specific
requirements and will need tighter control of its syscalls anyway.

(Eventually, support for setting the file owner and group atomically
could be added by writing out a file using `O_TMPFILE` so it’s not
addressable, and then linking it into the file system in place of the
old file using something like `renameat2(AT_EMPTY_PATH)` or `linkat()`.
That’s currently not possible without patching the kernel with
https://marc.info/?l=linux-fsdevel&m=152472898003523&w=2, as far as I
know at the moment.)
Signed-off-by: Philip Withnall <withnall@endlessm.com>

Fixes: #1203

This moves `write_to_temp_file()` into `g_file_set_contents_full()` and
coalesces its handling of `do_fsync` with the `rename_file()` call. It
adds support for `G_FILE_SET_CONTENTS_DURABLE` and
`G_FILE_SET_CONTENTS_NONE` — previously only
`G_FILE_SET_CONTENTS_CONSISTENT | G_FILE_SET_CONTENTS_ONLY_EXISTING` was
supported.

In the case that `G_FILE_SET_CONTENTS_CONSISTENT |
G_FILE_SET_CONTENTS_DURABLE` is set, an additional `fsync()` is now done
on the directory after renaming the temporary file.

In the case that `G_FILE_SET_CONTENTS_ONLY_EXISTING` isn’t set, the
`fsync()` after writing the temporary file will always be done (unless
the file system guarantees it never needs to be done).

In the case that only `G_FILE_SET_CONTENTS_DURABLE` is set, the
destination file will be written to directly (using this mode is not
really advised).
Signed-off-by: Philip Withnall <withnall@endlessm.com>

Fixes: #1302

We can guarantee that they’re non-negative.
Signed-off-by: Philip Withnall <withnall@endlessm.com>

Helps: #1302

This introduces no functional changes, just makes the code a bit more
modular and reusable.
Signed-off-by: Philip Withnall <withnall@endlessm.com>

Helps: #1302

This introduces no functional changes.
Signed-off-by: Philip Withnall <withnall@endlessm.com>

Helps: #1302

This is a new version of the g_file_set_contents() API which will allow
its safety to be controlled by some flags, allowing the user to choose
their preferred tradeoff between safety (`fsync()` calls) and speed.

Currently, the flags do nothing and the new API behaves like the old
API. This will change in the following commits.
Signed-off-by: Philip Withnall <withnall@endlessm.com>

Helps: #1302

Fix non-utf8 URI pct-decoding / unescape regression

Closes #2165

See merge request !1569

gmain: fix fetching timebase on non-Intel Darwin

Closes #858

See merge request !1566

The previous implementation of g_uri_unescape_segment() allowed non-utf8
decoded characters. uri_decoder() allows it too with FLAGS_ENCODED (I
think it's abusing a bit the user-facing flags for some internal
decoding behaviour)

However, it didn't allow \0 in the decoded string. Let's have an extra
check for that, outside of uri_decoder().

Fixes: d83d68d6Reported-by: Matthias Clasen <mclasen@redhat.com>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>

Suggested-by: Matthias Clasen <mclasen@redhat.com>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>

Fix giomodule.cache being wrongly considered stale

Closes #2127

See merge request !1560

glib.supp: Generalise some g_quark_init() suppressions

Closes #2132

See merge request !1543

tests: Add tests for RFC 8536 v3 parsing of time zones

See merge request !1578

gtask: Only override g_task_set_source_tag() for GLib ≥ 2.60

See merge request !1576

Fix support for binary xattrs

Closes #422

See merge request !1568

uri: add illegal_characters argument to unescape_bytes

See merge request !1577

Signed-off-by: Philip Withnall <withnall@endlessm.com>

Helps: #422

glib: Use g_getenv everywhere instead of getenv

See merge request !1579

`getenv()` doesn't work well on Windows, f.ex., it can't fetch env
vars set with `SetEnvironmentVariable()`. This also means that it
doesn't work at all when targeting UWP since that's the only way to
set env vars in that case.

This adds really basic validation that `GTimeZone` can successfully
parse a ‘slim’ format timezone file.
Signed-off-by: Philip Withnall <withnall@endlessm.com>

Helps: #2129

This will allow the following commit to refer to GitLab in its
`g_test_bug()` call.
Signed-off-by: Philip Withnall <withnall@endlessm.com>

GDateTime fixes to handle TZif footers

Closes #2129

See merge request !1533

* glib/gtimezone.c (set_tz_name): Use size, not NAME_SIZE,
to clear the buffer.  Suggested by Philip Withnall in:
!1533 (comment 867859)

Since tzcode95f (1995), TZif files have had a trailing
TZ string, used for timestamps after the last transition.
This string is specified in Internet RFC 8536 section 3.3.
init_zone_from_iana_info has ignored this string, causing it
to mishandle timestamps past the year 2038.  With zic's new -b
slim flag, init_zone_from_iana_info would even mishandle current
timestamps.  Fix this by parsing the trailing TZ string and adding
its transitions.

Closes #2129

Time zone transition times can range from -167:59:59 through
+167:59:59, according to Internet RFC 8536 section 3.3.1;
this is an extension to POSIX.  It is needed for proper
support of TZif version 3 files.

POSIX allows hh to be 24; see
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_03

TZ strings like '<-03>3' were introduced in POSIX 1003.1-2001 and
are currently specified in:
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_03

Version 3 was introduced in tzdb 2013e (2013).
See Internet RFC 8536 section 3.1 under "ver(sion)".

It's not clear to me why this argument was excluded in the first place,
and Dan doesn't remember either. At least for consistency with
unescape_string, add it.

See also:
!1574 (comment 867283)Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>

g_task_set_name() was added in GLib 2.60, so only use it in the
overridden definition of g_task_set_source_tag() if the user has said
that they require GLib ≥ 2.60.

This is a follow up to commit b08bd04a.
Signed-off-by: Philip Withnall <withnall@endlessm.com>

uri: fix g_uri_unescape_string() regression

Closes #2160

See merge request !1574

The illegal character set used to be applied only to the decoded
characters.

Fixes: #2160

Fixes: d83d68d6 ("guri: new URI parsing and generating functions")
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>