GLib merge requestshttps://gitlab.gnome.org/GNOME/glib/-/merge_requests2024-03-25T17:12:01Zhttps://gitlab.gnome.org/GNOME/glib/-/merge_requests/3939Add g_file_copy_async_with_closures() and g_file_move_async_with_closures()2024-03-25T17:12:01ZPhilip ChimentoAdd g_file_copy_async_with_closures() and g_file_move_async_with_closures()`g_file_copy_async()` and `g_file_move_async()` are written in a way that is not bindable with gobject-introspection. The progress callback data can be freed once the async callback has been called, which is convenient for C, but in lang...`g_file_copy_async()` and `g_file_move_async()` are written in a way that is not bindable with gobject-introspection. The progress callback data can be freed once the async callback has been called, which is convenient for C, but in language bindings the progress callback closure is currently just leaked.
There is no scope annotation that fits how the progress callback should be treated:
- `(scope call)` is correct for the sync versions of the functions, but incorrect for the async functions; the progress callback is called after the async functions return.
- `(scope notified)` is incorrect because there is no GDestroyNotify parameter, meaning the callback will always leak.
- `(scope async)` is incorrect because the callback is called more than once.
- `(scope forever)` is incorrect because the callback closure could be freed after the async callback runs.
This adds `g_file_copy_async_with_closures()` and `g_file_move_async_with_closures()` for the benefit of language bindings.
See: GNOME/gjs#590
Note, this is marked as a draft because as a new API, it should wait until the GNOME 47 cycle to land. There is a temporary commit incrementing the version so that we generate the correct visibility macros, which should disappear when rebasing next cycle. Despite the draft status, it is ready for review.2.82https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1840Add nullable annotation for g_file_get_uri_scheme2021-01-06T08:55:48ZSophie HeroldAdd nullable annotation for g_file_get_uri_schemehttps://gitlab.gnome.org/GNOME/glib/-/merge_requests/1549Add support to ignore trash for certain mounts2020-08-05T15:06:31ZOndrej HolyAdd support to ignore trash for certain mountsAdd support for `x-gvfs-notrash` mount option, which allows to disable
trash functionality for certain mounts. This might be especially useful
e.g. to prevent trash folder creation on enterprise shares, which are
also accessed from Wi...Add support for `x-gvfs-notrash` mount option, which allows to disable
trash functionality for certain mounts. This might be especially useful
e.g. to prevent trash folder creation on enterprise shares, which are
also accessed from Windows...
See also corresponding gvfs merge request:
https://gitlab.gnome.org/GNOME/gvfs/-/merge_requests/89
See corresponding bug reports:
- https://bugzilla.gnome.org/show_bug.cgi?id=729385
- https://bugzilla.redhat.com/show_bug.cgi?id=1096200https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3358Align `G_FILE_MEASURE_APPARENT_SIZE` behaviour with `du` from GNU coreutils 9.22023-05-23T12:00:25ZJoan BrugueraAlign `G_FILE_MEASURE_APPARENT_SIZE` behaviour with `du` from GNU coreutils 9.2This aligns the behaviour of GLib's `G_FILE_MEASURE_APPARENT_SIZE` flag with the behaviour of GNU Coreutils 9.2 `du`:
Since GNU Coreutils 9.2, `du --apparent-size` (including `du --bytes`) only counts the size of regular files and symli...This aligns the behaviour of GLib's `G_FILE_MEASURE_APPARENT_SIZE` flag with the behaviour of GNU Coreutils 9.2 `du`:
Since GNU Coreutils 9.2, `du --apparent-size` (including `du --bytes`) only counts the size of regular files and symlinks, it does no longer sum the `st_size` of other kinds of files (directories, FIFOs, etc.) for which `st_size` is not even defined by POSIX.
Note that this is may be a breaking change for some uses (though I believe `G_FILE_MEASURE_APPARENT_SIZE` is mostly designed for displaying sizes to users, so breakage shouldn't be very substantial).
This also fixes `test_measure` which was failing for GNU Coreutils 9.2+ (the test no longer depends on the system's `du` since there are multiple behaviours in the wild anyway).
Fixes: GNOME/glib#29652.78.0https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1142Backport !1134 Fix for file copy permissions to glib-2-622019-10-03T06:36:43ZPhilip WithnallBackport !1134 Fix for file copy permissions to glib-2-62Trivial backport of the important parts of !1134 to `glib-2-62`.Trivial backport of the important parts of !1134 to `glib-2-62`.2.62.1https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1447Backport !1442 “gfile: Fallback to fast-content-type if content-type is not s...2020-04-09T13:16:50ZPhilip WithnallBackport !1442 “gfile: Fallback to fast-content-type if content-type is not set” to glib-2-64The G_FILE_ATTRIBUTE_STANDARD_CONTENT_TYPE attribute doesn't have to be
always set. See https://gitlab.gnome.org/GNOME/gvfs/-/merge_requests/68
for more details. In that case, the g_file_query_default_handler function
fails with the "No ...The G_FILE_ATTRIBUTE_STANDARD_CONTENT_TYPE attribute doesn't have to be
always set. See https://gitlab.gnome.org/GNOME/gvfs/-/merge_requests/68
for more details. In that case, the g_file_query_default_handler function
fails with the "No application is registered as handling this file" error.
Let's fallback to the "standard::fast-content-type" attribute instead to
fix issues when opening such files.
https://gitlab.gnome.org/GNOME/nautilus/-/issues/1425
---
Trivial backport of !1442 to `glib-2-64`.2.64.2https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2141Backport !2138 “glocalfileoutputstream: Fix ETag check when replacing through...2021-06-10T12:49:35ZPhilip WithnallBackport !2138 “glocalfileoutputstream: Fix ETag check when replacing through a symlink” to glib-2-68Since commit 87e19535fe, the ETag check when writing out a file through
a symlink (following the symlink) has been incorrectly using the ETag
value of the symlink, rather than the target file. This is incorrect
because the ETag should re...Since commit 87e19535fe, the ETag check when writing out a file through
a symlink (following the symlink) has been incorrectly using the ETag
value of the symlink, rather than the target file. This is incorrect
because the ETag should represent the file content, not its metadata or
links to it.
Fix that, and add a unit test.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2417
---
Trivial backport of !2138 (excluding the second commit which was an incidental cleanup) to `glib-2-68`.2.68.3https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2186Backport !2185 “glocalfile: Fix the global trash dir detection” to glib-2-682021-07-12T11:10:24ZPhilip WithnallBackport !2185 “glocalfile: Fix the global trash dir detection” to glib-2-68The `g_file_trash` function fails with the `Unable to find or create trash
directory` error when the global `.Trash` directory exists. This is because
the commit 7f2af262 introduced the `gboolean success` variable to signalize
the detect...The `g_file_trash` function fails with the `Unable to find or create trash
directory` error when the global `.Trash` directory exists. This is because
the commit 7f2af262 introduced the `gboolean success` variable to signalize
the detection of the trash folder, but didn't set it in all code branches.
Since for a time this variable was not initialized the bug wasn't visible
when the trash folder existed. The bug became effective after the `success`
variable was initialized with `FALSE` by the commit c983ded0. Let's explicitly
set the `success` variable in all branches to fix the global trash dir
detection.
Fixes: https://gitlab.gnome.org/GNOME/glib/-/issues/2439
---
Trivial backport of !2185.2.68.4https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1982Backport !2325 “file-roller symlink attack” to glib-2-662021-03-10T19:07:52ZPhilip WithnallBackport !2325 “file-roller symlink attack” to glib-2-66Trivial backport of most of !1981, minus the large number of new tests.
Fixes: #2325Trivial backport of most of !1981, minus the large number of new tests.
Fixes: #23252.66.8https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2587Backport !2583 “Fix trashing sandboxed directories” to glib-2-722022-04-05T14:18:03ZPhilip WithnallBackport !2583 “Fix trashing sandboxed directories” to glib-2-72We must not open the fd with O_PATH|O_NOFOLLOW,
since the portal rejects that combination. Leaving
out O_NOFOLLOW is fine in this case - we know it
is a directory, we just received EISDIR.
Fixes: #2629
---
Trivial backport of !2583 to...We must not open the fd with O_PATH|O_NOFOLLOW,
since the portal rejects that combination. Leaving
out O_NOFOLLOW is fine in this case - we know it
is a directory, we just received EISDIR.
Fixes: #2629
---
Trivial backport of !2583 to `glib-2-72`.2.72.1Philip WithnallPhilip Withnallhttps://gitlab.gnome.org/GNOME/glib/-/merge_requests/2982Backport !2887 “glocalfileinfo: Ensure we always sniff some data to get the c...2022-10-20T12:56:18ZPhilip WithnallBackport !2887 “glocalfileinfo: Ensure we always sniff some data to get the content type” to glib-2-74In case the XDG database is not initialized yet we may try to sniff a
0-length data, making our content-type routines to mark non-empty files
as `application/x-zerosize`.
This is wrong, so in case the sniff size is not set, let's just
t...In case the XDG database is not initialized yet we may try to sniff a
0-length data, making our content-type routines to mark non-empty files
as `application/x-zerosize`.
This is wrong, so in case the sniff size is not set, let's just
try to read the default value. To avoid false-application/x-zerosize
results (that are not something we want as per legacy assumptions).
See: https://bugzilla.gnome.org/show_bug.cgi?id=755795
Fixes: https://gitlab.gnome.org/GNOME/glib/-/issues/2742
---
Trivial backport of !2887 to `glib-2-74`.2.74.1Philip WithnallPhilip Withnallhttps://gitlab.gnome.org/GNOME/glib/-/merge_requests/878Backport !876 “gfile: Limit access to files when copying” to glib-2-602019-06-04T10:09:30ZPhilip WithnallBackport !876 “gfile: Limit access to files when copying” to glib-2-60file_copy_fallback creates new files with default permissions and
set the correct permissions after the operation is finished. This
might cause that the files can be accessible by more users during
the operation than expected. Use G_FILE...file_copy_fallback creates new files with default permissions and
set the correct permissions after the operation is finished. This
might cause that the files can be accessible by more users during
the operation than expected. Use G_FILE_CREATE_PRIVATE for the new
files to limit access to those files.
---
Trivial backport of !876.2.60.4Ondrej HolyOndrej Holyhttps://gitlab.gnome.org/GNOME/glib/-/merge_requests/1061Backport !966 “Resolve "Invalid characters in Open Location dialog crashes GI...2019-08-27T07:28:32ZPhilip WithnallBackport !966 “Resolve "Invalid characters in Open Location dialog crashes GIMP"” to glib-2-60Backport of !966 to `glib-2-60`. Trivial backport.Backport of !966 to `glib-2-60`. Trivial backport.https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3115ci: Don’t fail if testlog-unstable_tests.junit.xml doesn’t exist on MSVC2022-12-09T10:07:39ZPhilip Withnallci: Don’t fail if testlog-unstable_tests.junit.xml doesn’t exist on MSVCThat file is created if running the `unstable_tests` suite succeeds. It
can fail, though, leaving that log file nonexistent. There’s no point in
failing the whole test run by bailing out if postprocessing the log file
fails.
Occasionall...That file is created if running the `unstable_tests` suite succeeds. It
can fail, though, leaving that log file nonexistent. There’s no point in
failing the whole test run by bailing out if postprocessing the log file
fails.
Occasionally postprocessing can fail with a `FileNotFoundError`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>Philip WithnallPhilip Withnallhttps://gitlab.gnome.org/GNOME/glib/-/merge_requests/3292Close-on-exec flag few missed places2023-02-22T13:07:36ZMaciej S. SzmigieroClose-on-exec flag few missed placesIt looks like when scanning for file-descriptor-opening functions for !3283 I missed a few places:
* One case of `fopen ()` call which was written as `fopen()` (without space before the opening parenthesis).
Rescanned Glib code after thi...It looks like when scanning for file-descriptor-opening functions for !3283 I missed a few places:
* One case of `fopen ()` call which was written as `fopen()` (without space before the opening parenthesis).
Rescanned Glib code after this for another function calls written this way, found none relevant.
* Went thorough glibc man pages and Linux man-pages looking for other functions that mention the close-on-exec flag.
Within this set of file-descriptor-opening functions, I've spotted calls to `setmntent ()` and `mkstemp ()`-like family of functions in Glib.
Sorry for missing these cases for the previous MR a few days ago.https://gitlab.gnome.org/GNOME/glib/-/merge_requests/876CVE-2019-12450: gfile: Limit access to files when copying2019-09-30T13:41:57ZOndrej HolyCVE-2019-12450: gfile: Limit access to files when copyingfile_copy_fallback creates new files with default permissions and
set the correct permissions after the operation is finished. This
might cause that the files can be accessible by more users during
the operation than expected. Use G_FILE...file_copy_fallback creates new files with default permissions and
set the correct permissions after the operation is finished. This
might cause that the files can be accessible by more users during
the operation than expected. Use G_FILE_CREATE_PRIVATE for the new
files to limit access to those files.2.60.4https://gitlab.gnome.org/GNOME/glib/-/merge_requests/122Document why g_file_dup() is useful, instead of g_object_ref()2018-06-19T14:01:17ZPhilip WithnallDocument why g_file_dup() is useful, instead of g_object_ref()Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/807
Closes #807Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/807
Closes #807https://gitlab.gnome.org/GNOME/glib/-/merge_requests/577Don't fail trash test if ~/.local doesn't exist or mount points can't be dete...2019-01-18T15:16:24ZSimon McVittieDon't fail trash test if ~/.local doesn't exist or mount points can't be determinedSee #1643. I think we probably want at least the first commit, and perhaps the second too?
This is against glib-2-58 for now, because that's the version whose build failures I was looking into.See #1643. I think we probably want at least the first commit, and perhaps the second too?
This is against glib-2-58 for now, because that's the version whose build failures I was looking into.2.58.3Ondrej HolyOndrej Holyhttps://gitlab.gnome.org/GNOME/glib/-/merge_requests/593Don't fail trash test if ~/.local doesn't exist or mount points can't be dete...2019-02-01T11:36:23ZIain LaneDon't fail trash test if ~/.local doesn't exist or mount points can't be determined (master)master version of !577 [which builds OK on Launchpad](https://launchpadlibrarian.net/406605639/buildlog_ubuntu-disco-amd64.glib2.0_2.59.0-1~test2_BUILDING.txt.gz).
cc @oholy
also @smcv (I spoke with @oholy on IRC, who said that it...master version of !577 [which builds OK on Launchpad](https://launchpadlibrarian.net/406605639/buildlog_ubuntu-disco-amd64.glib2.0_2.59.0-1~test2_BUILDING.txt.gz).
cc @oholy
also @smcv (I spoke with @oholy on IRC, who said that it'd be good to see this in master at least for the time being.)
See #1643https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3938Draft: GWinHttpVfs Cleanup2024-03-21T23:55:43ZLuca Bacciluca.bacci@outlook.comDraft: GWinHttpVfs CleanupThe `winhttp.h` header was included in mingw-w64 in 2010: https://github.com/mirror/mingw-w64/commit/e5779dae. Moreover, `winhttp.dll` is always present [since Windows XP SP1](https://learn.microsoft.com/en-us/windows/win32/winhttp/what-...The `winhttp.h` header was included in mingw-w64 in 2010: https://github.com/mirror/mingw-w64/commit/e5779dae. Moreover, `winhttp.dll` is always present [since Windows XP SP1](https://learn.microsoft.com/en-us/windows/win32/winhttp/what-s-new-in-winhttp-5-1#redistribution), so there's no need to load it dynamically2.82