GLib issueshttps://gitlab.gnome.org/GNOME/glib/-/issues2024-03-07T19:31:17Zhttps://gitlab.gnome.org/GNOME/glib/-/issues/3280glocalfileinfo returns GFileInfo for anything inside a non-readable directory2024-03-07T19:31:17ZLuca Bacciluca.bacci@outlook.comglocalfileinfo returns GFileInfo for anything inside a non-readable directory`g_file_query_info` returns `NULL` if a resource doesn't exist. However, in the case of local files, if a dir component of the path is not readable then gio will return made-up values:
```
$ mkdir test
$ gio info test/file
gio: file:///...`g_file_query_info` returns `NULL` if a resource doesn't exist. However, in the case of local files, if a dir component of the path is not readable then gio will return made-up values:
```
$ mkdir test
$ gio info test/file
gio: file:///mnt/store/test/file: Error when getting information for file ?/mnt/store/test/file?: No such file or directory
$ chmod 000 test
$ gio info test/file
display name: file
edit name: file
name: file
uri: file:///mnt/store/test/file
local path: /mnt/store/test/file
unix mount: /dev/sda5 /mnt/store ext4 rw,relatime,x-gvfs-show,x-gvfs-name=Store
attributes:
standard::is-hidden: FALSE
standard::is-backup: FALSE
standard::is-symlink: FALSE
standard::name: file
standard::display-name: file
standard::edit-name: file
standard::copy-name: file
standard::icon: application-octet-stream, application-x-generic, application-octet-stream-symbolic, application-x-generic-symbolic
standard::content-type: application/octet-stream
standard::fast-content-type: application/octet-stream
standard::symbolic-icon: application-octet-stream-symbolic, application-x-generic-symbolic, application-octet-stream, application-x-generic
```
Here's the outcome with `stat`:
```
$ mkdir test
$ stat test/file
stat: cannot statx 'test/file': No such file or directory
$ chmod 000 test
$ stat test/file
stat: cannot statx 'test/file': Permission denied
```https://gitlab.gnome.org/GNOME/glib/-/issues/3279Win32: GIO doesn't set standard::type for the System Volume Information direc...2024-03-07T12:56:39ZLuca Bacciluca.bacci@outlook.comWin32: GIO doesn't set standard::type for the System Volume Information directoryWe get some criticals when using the `GtkFileChooserDialog`:
```
(gimp-2.99.exe:16668): GLib-GIO-CRITICAL **: 18:29:55.384: GFileInfo created without standard::type
(gimp-2.99.exe:16668): GLib-GIO-CRITICAL **: 18:29:55.389: file ../gli...We get some criticals when using the `GtkFileChooserDialog`:
```
(gimp-2.99.exe:16668): GLib-GIO-CRITICAL **: 18:29:55.384: GFileInfo created without standard::type
(gimp-2.99.exe:16668): GLib-GIO-CRITICAL **: 18:29:55.389: file ../glib-2.78.4/gio/gfileinfo.c: line 1611 (g_file_info_get_file_type): should not be reached
(gimp-2.99.exe:16668): GLib-GIO-CRITICAL **: 18:29:56.381: GFileInfo created without standard::type
(gimp-2.99.exe:16668): GLib-GIO-CRITICAL **: 18:29:56.387: file ../glib-2.78.4/gio/gfileinfo.c: line 1611 (g_file_info_get_file_type): should not be reached
```
That happens e.g for the `System Volume Information` directory that the OS creates at the root of drives (volumes). [Our stat](https://gitlab.gnome.org/GNOME/glib/-/blob/2.79.3/glib/gstdio.c?ref_type=tags#L585) implementation uses `CreateFile` to get informations about the file. As we don't really have access to the file due to the ACL, we should fallback to `GetFileAttributes`. Explorer shows a folder icon, which means the we can get the type informations.
Similar issues exist for:
* `C:\swapfile.sys`
* `C:\pagefile.sys`
* `C:\hiberfil.sys`
* etc.Luca Bacciluca.bacci@outlook.comLuca Bacciluca.bacci@outlook.comhttps://gitlab.gnome.org/GNOME/glib/-/issues/3104Nautilus doesn't open symlink right on an ntfs filesystem mounted with ntfs32023-09-11T07:39:10ZZhafran Rama AzmiNautilus doesn't open symlink right on an ntfs filesystem mounted with ntfs3<!--
Please test if the issue has already been fixed in the Nightly version.
You can install the Nightly version in parallel with the regular version with these instructions:
1. Make sure that Flatpak is installed (see http...<!--
Please test if the issue has already been fixed in the Nightly version.
You can install the Nightly version in parallel with the regular version with these instructions:
1. Make sure that Flatpak is installed (see https://flatpak.org/setup )
2. Copy and run the following command in a Terminal:
flatpak install --from https://nightly.gnome.org/repo/appstream/org.gnome.NautilusDevel.flatpakref
3) The Nightly version can now be launched from Activities, or with this command: flatpak run org.gnome.NautilusDevel
-->
# Affected version
- Nightly flatpak: Yes
- Other: 44.2.1
# Steps to reproduce
<!--
Explain in detail the steps on how the issue can be reproduced.
-->
1. Create a symlink in an ntfs filesystem mounted with the `ntfs3` drriver
2. Try to open symlink in Nautilus
# Current behavior
<!-- Describe the current behavior. -->
Nautilus doesn't open symlink's target.
# Expected behavior
<!-- Describe the expected behavior. -->
Nautilus to open symlink's target.
# Additional information
<!--
Provide more information that could be relevant.
If the issue is a crash, provide a stack trace following the steps in:
https://wiki.gnome.org/Community/GettingInTouch/Bugzilla/GettingTraces
-->
<!-- Ignore the text under this line. -->https://gitlab.gnome.org/GNOME/glib/-/issues/3077Inherited NFSv4 ACLs are overwritten when moving a file2023-08-29T15:01:40ZEvin TechnikInherited NFSv4 ACLs are overwritten when moving a file- OS: Ubuntu 22.04
- glib version: 2.72.4
# Description
We are mounting an NFS share from an NFS server (FreeBSD 13). Authorization to
directories in that share is enforced through NFSv4 ACLs on the server. When
copying or moving a fil...- OS: Ubuntu 22.04
- glib version: 2.72.4
# Description
We are mounting an NFS share from an NFS server (FreeBSD 13). Authorization to
directories in that share is enforced through NFSv4 ACLs on the server. When
copying or moving a file to the share, it will inherit ACLs from the destination
directory.
In most of the cases this works fine. However, when we move a file that has ACLs
to a directory in the share using Nautilus or "gio move", the ACL inheritance
goes wrong. The destination file will end up with the original ACLs (the ACLs it
had in the source location) instead of the ACLs that are inherited by the
destination directory.
This behaviour changed when we upgraded from Ubuntu 20.04 to Ubuntu 22.04. In
Ubuntu 20.04 the ACL inheritance worked as expected.
I assume what happens is the following:
1. A server-side move is performed
2. The destination file is assigned ACLs (they are inherited from the destination directory)
3. glib overwrites the ACLs of the destination file with the original ACLs
To workaround the issue we patched glib and removed a call to
g_file_set_attributes_from_info, see the attached patch ([disable-setting-ACL-attributes.patch](/uploads/790f0a5508f90f11eaf3d3f591479765/disable-setting-ACL-attributes.patch)). This brings the
expected behaviour but may have unintended side effects.
# Steps to Reproduce
1. on the server (FreeBSD): prepare two directories A and B and assign the following NFSv4 ACLs:
```
# file: A
# owner: root
# group: wheel
user:alice:rwx--daARWc--s:fd-----:allow
owner@:rwxp-daARWc--s:fd-----:allow
group@:------a-R-c--s:fd-----:allow
everyone@:------a-R-c--s:fd-----:allow
# file: B
# owner: root
# group: wheel
user:alice:rwx--daARWc--s:fd-----:allow
user:bob:rwx--daARWc--s:fd-----:allow
owner@:rwxp-daARWc--s:fd-----:allow
group@:------a-R-c--s:fd-----:allow
everyone@:------a-R-c--s:fd-----:allow
```
Note the inheritance flags (fd), which indicate that files in the directories will inherit the ACLs.
2. on the client (Ubuntu): mount the NFS share to /mnt using credentials of user "alice"
3. on the client: echo "hello world" > /mnt/A/test.txt
4. on the server: list the ACLs of A/test.txt:
```
# file: A/test.txt
# owner: alice
# group: wheel
user:alice:rw---daARWc--s:------I:allow
owner@:rw-p-daARWc--s:------I:allow
group@:------a-R-c--s:------I:allow
everyone@:------a-R-c--s:------I:allow
```
5. on the client: gio move /mnt/A/test.txt /mnt/B/test.txt
6. on the server: list the ACLs of B/test.txt
```
# file: B/test.txt
# owner: alice
# group: wheel
user:alice:rw---daARWc--s:------I:allow
owner@:rw-p-daARWc--s:------I:allow
group@:------a-R-c--s:------I:allow
everyone@:------a-R-c--s:------I:allow
```
We expected an ACE for user bob, but it is missing.https://gitlab.gnome.org/GNOME/glib/-/issues/3070gio/g-file-info test fails on macOS2023-08-11T17:33:27ZRené de Hessellegio/g-file-info test fails on macOSThis issue is a follow-up activity to https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3503.
The `glib:gio / g-file-info` test fails on macOS:
```
225/320 glib:gio / g-file-info RUNNING ...This issue is a follow-up activity to https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3503.
The `glib:gio / g-file-info` test fails on macOS:
```
225/320 glib:gio / g-file-info RUNNING
>>> G_ENABLE_DIAGNOSTIC=1 GIO_MODULE_DIR='' G_TEST_SRCDIR=/Users/Shared/work/5uAdP8-e/0/dehesselle/glib/gio/tests MALLOC_CHECK_=2 G_DEBUG=gc-friendly G_TEST_BUILDDIR=/Users/Shared/work/5uAdP8-e/0/dehesselle/glib/_build/gio/tests MALLOC_PERTURB_=43 /Users/Shared/work/5uAdP8-e/0/dehesselle/glib/_build/gio/tests/g-file-info
▶ 225/320 /g-file-info/test_g_file_info OK
▶ 225/320 /g-file-info/xattrs OK
▶ 225/320 /g-file-info/test_g_file_info/modification-time - GLib-GIO:ERROR:../gio/tests/g-file-info.c:250:test_g_file_info_modification_time: assertion failed (new_nsecs == nsecs + 100): (0 == 100) FAIL
▶ 225/320 ERROR
225/320 glib:gio / g-file-info ERROR 0.50s killed by signal 6 SIGABRT
――――――――――――――――――――――――――――――――――――― ✀ ―――――――――――――――――――――――――――――――――――――
stderr:
**
GLib-GIO:ERROR:../gio/tests/g-file-info.c:250:test_g_file_info_modification_time: assertion failed (new_nsecs == nsecs + 100): (0 == 100)
(test program exited with status code -6)
――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
```
This test is being disabled in `meson.build` so that macOS CI can pass.https://gitlab.gnome.org/GNOME/glib/-/issues/2696Add compressed size attribute for btrfs compressed files2022-07-25T11:12:50ZDmitriy BatsmanAdd compressed size attribute for btrfs compressed filesPlease implement an attribute to see the size of files/directories in compressed form, in addition to the normal size. For use by GTK applications and file managers. Primarily due to the growing popularity of BTRFS, but there are others ...Please implement an attribute to see the size of files/directories in compressed form, in addition to the normal size. For use by GTK applications and file managers. Primarily due to the growing popularity of BTRFS, but there are others as well.
P.S. For F2FS implementation in question, a vote is needed here. After all, it is used there to reduce wear and tear, but blocks are still used.https://gitlab.gnome.org/GNOME/glib/-/issues/2513GFile utf8 xattr attributes behaviour2021-12-13T12:58:00ZMarc-André LureauGFile utf8 xattr attributes behaviourAccording to `g_file_info_set_attribute_string()`, `@attr_value` is a utf8 string.
But this isn't being tested in `tests/g-file-info.c`. Instead, escaped strings are tested...
For some reason, in set_xattr() (https://gitlab.gnome.org/G...According to `g_file_info_set_attribute_string()`, `@attr_value` is a utf8 string.
But this isn't being tested in `tests/g-file-info.c`. Instead, escaped strings are tested...
For some reason, in set_xattr() (https://gitlab.gnome.org/GNOME/glib/-/blob/main/gio/glocalfileinfo.c#L798), the value is unescaped. That's somewhat unexpected, and should be documented (which escape format?).
On get_one_xattr() path (https://gitlab.gnome.org/GNOME/glib/-/blob/main/gio/glocalfileinfo.c#L416), the value is escaped back, which results in different values from what was set with valid utf8 strings.https://gitlab.gnome.org/GNOME/glib/-/issues/2318localfileinfo: readlink() buffer allocation needs overflow protection2021-02-04T07:34:52ZSebastian Drögelocalfileinfo: readlink() buffer allocation needs overflow protectionThe following discussion from !1918 should be addressed:
- [ ] @sdroege started a [discussion](https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1918#note_1024598): (+5 comments)
> Needs an overflow check (someone should some d...The following discussion from !1918 should be addressed:
- [ ] @sdroege started a [discussion](https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1918#note_1024598): (+5 comments)
> Needs an overflow check (someone should some day go through all the `g_realloc()` calls and check them for the same pattern)
----
Should also check if any other such cases exist in this file at least.https://gitlab.gnome.org/GNOME/glib/-/issues/2272gvfs/gio variable range overflow for mtime before 1970-01-012021-01-04T14:53:58ZChristoph Finkgvfs/gio variable range overflow for mtime before 1970-01-01gio seems to hit some kind of variable range underrun/overrun for files that have a modification time before epoch 0.
```
$ touch -d @0 this-is-old
$ gio info this-is-old |grep 'time::modified:'
time::modified: 0
```
```
$ touch -d @...gio seems to hit some kind of variable range underrun/overrun for files that have a modification time before epoch 0.
```
$ touch -d @0 this-is-old
$ gio info this-is-old |grep 'time::modified:'
time::modified: 0
```
```
$ touch -d @-1 this-is-old
$ gio info this-is-old |grep 'time::modified:'
time::modified: 18446744073709551615
```
I think it’s not an entirely absurd use case to have files with a ctime, atime or mtime set to relatively old dates, think of archival reasons, or even a photo album.
This might be the underlying cause of this issue in tracker: https://gitlab.gnome.org/GNOME/tracker-miners/-/issues/155https://gitlab.gnome.org/GNOME/glib/-/issues/2263file open dialogue takes long time to display folder content in NAS directori...2020-12-08T06:09:41ZMacchiato17file open dialogue takes long time to display folder content in NAS directories on Windows## Current behavior
Under Windows 10 I experience a very long delay when opening a file-open dialogue from GTK based applications (e.g. GIMP, darktable, etc.). In a NAS based directory, I have about 1000 sub-folders. After clicking on th...## Current behavior
Under Windows 10 I experience a very long delay when opening a file-open dialogue from GTK based applications (e.g. GIMP, darktable, etc.). In a NAS based directory, I have about 1000 sub-folders. After clicking on the parent folder holding the 1000 sub-folders, I need to wait quite some time until I'm able to select or browse into a desired sub-folder.
## Expected outcome
Could you please use a faster function to get the directory contents from the network drive. This should be a realistic option from my understanding, since opening the folder with Windows Explorer and displaying the 1000 sub-folder items takes about 1s, in GTK based applications, it takes 30s after clicking the application-related "open..." button.
Additional suggestion: it would be quite nice, if you could allow to paste a target folder path directly into the path selection like Windows Explorer allows the user to do. This would allow for direct selection of the target folder without the need of browsing from the top folder. I recently learned, that this can be achieved by pressing "CTRL-L", but this short-cut is not quite intuitive nor easy to guess from the current layout of the file* dialogues.
## Additional information
Environment
Windows 10 professional 64 Bit client, connected to network via Wi-Fi 5 (802.11ac) at ~500Mbit/s with low latency of 1-2ms router connection / NAS based album folder (SMB 3), attached to the WiFi router via 1GBit Ethernet LANhttps://gitlab.gnome.org/GNOME/glib/-/issues/1722trash requirements restrictive and inconsistent for non-system mounts2019-03-15T21:49:40Zbrainchildtrash requirements restrictive and inconsistent for non-system mounts# Background
[The FreeDesktop.org Trash specification](https://specifications.freedesktop.org/trash-spec/trashspec-latest.html) explains where compliant applications should look when attempting to resolve the trash location for a partic...# Background
[The FreeDesktop.org Trash specification](https://specifications.freedesktop.org/trash-spec/trashspec-latest.html) explains where compliant applications should look when attempting to resolve the trash location for a particular store. Specific, restrictive ownership and permissions requirements are described, with the suggestion that these requirements may be relaxed for stores that lack a full POSIX permissions scheme. However, no further details are offered on this issue.
In a specific common use case, a user will attach removable media to a system.
In such cases, any or several of the following are highly likely to apply:
1. The file system is not a Linux type.
2. The UID layout for the file system does not concord with that of the host system.
3. The file system is mounted such that all files appear with a particular owner, group, and permissions set, for example, root.root and 0666/0777.
Any of the above conditions alone is sufficient for particular requirements given in the specification to become too restrictive for practical use.
This reality is reflected in part by the current behavior of GIO, which searches locations with a less restrictive permissions set when listing current trash contents. However, this practical, relaxed interpretation does not carry into the case of moving items to trash.
Message boards on this subject currently offer suggestions for mounting an NTFS volume as a particular user (e.g. 1000) on the host system, to work around the above restrictions. Such approaches are inconvenient and carry significant side effects. One prominent side effect is lack of support for multiple users on the host system using the same removable media, a case sadly overlooked by many Linux desktop distributions.
# Suggestion
Relax some or all of the following requirements, and perhaps others relevant but not listed, for trash locations for certain mounted volumes:
1. Trash location is user owned.
2. Trash location has sticky bit set.
# Further Notes
- Currently, when finding a trash location fails, a non-specific message is produced, making it impossible to determine the changes needed in the volume to resolve the issue. This problem is already separately documented in #1283. The current issue is related but not a duplicate.
- GIO-based file shares ought also to be considered when addressing this issue. For example, GNOME-family file managers currently behave differently with respect to trash management for the same network share, depending on whether the share is accessed as a NFS system mount or GIO SMB share, with the behavior in the former case being more friendly to the user. Users expect that the application interact with the same storage device uniformly, with artifacts of the particular access method creating minimal degradation of the experience.https://gitlab.gnome.org/GNOME/glib/-/issues/1404Support FreeBSD extattr API2021-10-25T09:53:37ZTing-Wei LanSupport FreeBSD extattr APIFreeBSD supports extended attributes. However, its API is different from Linux xattr, so we have to disable xattr support in order to build GLib on FreeBSD. It will be nice if GLib can include support for FreeBSD extattr.
Link to extatt...FreeBSD supports extended attributes. However, its API is different from Linux xattr, so we have to disable xattr support in order to build GLib on FreeBSD. It will be nice if GLib can include support for FreeBSD extattr.
Link to extattr(2) man page: https://man.freebsd.org/extattr(2).https://gitlab.gnome.org/GNOME/glib/-/issues/1268glocalfileinfo: Use AT_NO_AUTOMOUNT for .hidden file2022-08-15T13:21:29ZBugzillaglocalfileinfo: Use AT_NO_AUTOMOUNT for .hidden file## Submitted by Colin Walters `@walters`
**[Link to original bug (#782554)](https://bugzilla.gnome.org/show_bug.cgi?id=782554)**
## Description
In an autofs setup with dynamic mounts for e.g. `/home`, having
Nautilus look at `/home/...## Submitted by Colin Walters `@walters`
**[Link to original bug (#782554)](https://bugzilla.gnome.org/show_bug.cgi?id=782554)**
## Description
In an autofs setup with dynamic mounts for e.g. `/home`, having
Nautilus look at `/home/.hidden` can force automounting when
it's unnecessary.
In practice today, `AT_NO_AUTOMOUNT` isn't honored by Linux,
but that's going to be fixed:
http://marc.info/?l=linux-fsdevel&m=149438995526466&w=2
So let's start using this in preparation for that.
See https://bugzilla.redhat.com/show_bug.cgi?id=1437754https://gitlab.gnome.org/GNOME/glib/-/issues/809_g_local_file_info_get doesn't return an error if it gets an EACCES2024-03-07T19:31:18ZBugzilla_g_local_file_info_get doesn't return an error if it gets an EACCES## Submitted by John Hughes
**[Link to original bug (#721630)](https://bugzilla.gnome.org/show_bug.cgi?id=721630)**
## Description
_g_local_file_info_get deliberately ignores EACCES, this was done to fix RedHat [bug 586412](https://...## Submitted by John Hughes
**[Link to original bug (#721630)](https://bugzilla.gnome.org/show_bug.cgi?id=721630)**
## Description
_g_local_file_info_get deliberately ignores EACCES, this was done to fix RedHat [bug 586412](https://bugzilla.gnome.org/show_bug.cgi?id=586412)
A side effect of this change is that if /usr/local is an nfs4 directory mounted with sec=krb5 and the gdm3 user doesn't have a Kerberos ticket then gnome-shell thinks the /usr/local/share/gnome-shell/modes directory exists (because glib doesn't tell it about the EACCES error) but it can't read it.
Due to [bug 721629](https://bugzilla.gnome.org/show_bug.cgi?id=721629) this leaves the user without the gdm3 login screen.
(This is Debian [bug 734141](https://bugzilla.gnome.org/show_bug.cgi?id=734141))
Version: 2.36.xhttps://gitlab.gnome.org/GNOME/glib/-/issues/654Support shared thumbnail repositories for querying GLocalFileInfo thumbnails2020-06-25T12:21:23ZBugzillaSupport shared thumbnail repositories for querying GLocalFileInfo thumbnails## Submitted by Jonathan Csanyi
**[Link to original bug (#691460)](https://bugzilla.gnome.org/show_bug.cgi?id=691460)**
## Description
The Thumbnail Managing Standard describes support for read-only "shared thumbnail repositories", ...## Submitted by Jonathan Csanyi
**[Link to original bug (#691460)](https://bugzilla.gnome.org/show_bug.cgi?id=691460)**
## Description
The Thumbnail Managing Standard describes support for read-only "shared thumbnail repositories", which can be distributed alongside a set of images (on a CD, or a network share, for example).
This is implemented by means of a .sh_thumbnails subdirectory (sitting alongside the images themselves) containing the same "fail", "normal", and "large" subdirectories that exist in the normal thumbnail cache.
Nautilus should check if the shared thumbnails exists, and use them if possible before trying to create new local thumbnails.
http://standards.freedesktop.org/thumbnail-spec/0.7.0/x320.htmlhttps://gitlab.gnome.org/GNOME/glib/-/issues/526no alphabetic order of the files on Mac OS X2020-01-29T13:51:33ZBugzillano alphabetic order of the files on Mac OS X## Submitted by goe..@..web.de
**[Link to original bug (#672336)](https://bugzilla.gnome.org/show_bug.cgi?id=672336)**
## Description
have a look at the attached screenshots. i click twice on "name" and in no way the files are in al...## Submitted by goe..@..web.de
**[Link to original bug (#672336)](https://bugzilla.gnome.org/show_bug.cgi?id=672336)**
## Description
have a look at the attached screenshots. i click twice on "name" and in no way the files are in alphabetic order.https://gitlab.gnome.org/GNOME/glib/-/issues/434gedit breaks use of user_xattrs2021-10-25T09:53:37ZBugzillagedit breaks use of user_xattrs## Submitted by Christoph Anton Mitterer
**[Link to original bug (#656052)](https://bugzilla.gnome.org/show_bug.cgi?id=656052)**
## Description
Hi.
It seems that gedit breaks the usage of at least user_xattrs (and probably of XATTR...## Submitted by Christoph Anton Mitterer
**[Link to original bug (#656052)](https://bugzilla.gnome.org/show_bug.cgi?id=656052)**
## Description
Hi.
It seems that gedit breaks the usage of at least user_xattrs (and probably of XATTRs and ACLs in general).
When setting user_xattrs on any files these are lost as soon as I save the file in gedit.
I presume that gedit rewrites them files as new files?!
Not sure what should happen in case of "save as...", whether this should preserve xattrs/acls or not.
Marking this as critical, as it could impose security issues, especially when the user_xattrs are somehow security relevant (e.g. used by intrusion detection systems or so)
Cheers,
Chris.
Version: 2.46.xhttps://gitlab.gnome.org/GNOME/glib/-/issues/392setting file attributes2020-01-29T16:23:17ZBugzillasetting file attributes## Submitted by John E
**[Link to original bug (#641705)](https://bugzilla.gnome.org/show_bug.cgi?id=641705)**
## Description
I'm using this code to attempt to set a file's 'hidden' attribute (glib-win32):-
void SetHiddenAttribute ...## Submitted by John E
**[Link to original bug (#641705)](https://bugzilla.gnome.org/show_bug.cgi?id=641705)**
## Description
I'm using this code to attempt to set a file's 'hidden' attribute (glib-win32):-
void SetHiddenAttribute (GFile* pFile, GFileInfo* pInfo, GError** ppError)
{
/* 'pInfo' was already initialized for the 'hidden'
* attribute, before calling this function */
g_file_info_set_is_hidden (pinfo, true);
g_file_set_attributes_from_info (pFile, pInfo,
G_FILE_QUERY_INFO_NOFOLLOW_SYMLINKS, NULL, ppError);
}
Even if the supplied parameters are valid, g_file_set_attributes_from_info() seems to return this error:-
error code 15 : message=0x02894d80 "Setting attribute standard::is-hidden not supported"
After a discussion on the gtk-app-devel mailing list, the consensus was that 'getting' a hidden attribute is currently supported, but not 'setting'. In fact, I haven't had much success getting or setting anything to do with attributes / modification times etc on the Windows platform (although to be fair, I haven't tried very many).
Can anyone tell me if the above code should work? If not could I propose it as a feature request?
Version: 2.24.x