g-object, common-lisp:standard-object, common-lisp:t

None

The g-file interface is a high level abstraction for manipulating files on a virtual file system. The g-file objects are lightweight, immutable objects that do no I/O upon creation. It is necessary to understand that g-file objects do not represent files, merely an identifier for a file. All file content I/O is implemented as streaming operations, see GInputStream and GOutputStream.

To construct a g-file object, you can use: the g-file-new-for-path function if you have a path. The g-file-new-for-uri function if you have a URI. The g-file-new-for-commandline-arg function for a command line argument. The g-file-new-tmp function to create a temporary file from a template. The g-file-parse-name function from a UTF-8 string gotten from the g-file-get-parse-name function.

One way to think of a g-file object is as an abstraction of a pathname. For normal files the system pathname is what is stored internally, but as g-file objects are extensible it could also be something else that corresponds to a pathname in a userspace implementation of a filesystem.

The g-file object make up hierarchies of directories and files that correspond to the files on a filesystem. You can move through the file system with the g-file object using the g-file-get-parent function to get an identifier for the parent directory, the g-file-get-child function to get a child within a directory, the g-file-resolve-relative-path function to resolve a relative path between two g-file objects. There can be multiple hierarchies, so you may not end up at the same root if you repeatedly call the g-file-get-parent function on two different files.

All g-file objects have a basename, get with the g-file-get-basename function. These names are byte strings that are used to identify the file on the filesystem, relative to its parent directory, and there is no guarantees that they have any particular charset encoding or even make any sense at all. If you want to use filenames in a user interface you should use the display name that you can get by requesting the "standard::display-name" attribute with the g-file-query-info function. This is guaranteed to be in UTF-8 and can be used in a user interface. But always store the real basename or the g-file object to use to actually access the file, because there is no way to go from a display name to the actual name.

Using the g-file object as an identifier has the same weaknesses as using a path in that there may be multiple aliases for the same file. For instance, hard or soft links may cause two different g-file objects to refer to the same file. Other possible causes for aliases are: case insensitive filesystems, short and long names on Fat/NTFS, or bind mounts in Linux. If you want to check if two f-file objects point to the same file you can query for the "id::file" attribute. Note that the g-file object does some trivial canonicalization of pathnames passed in, so that trivial differences in the path string used at creation, duplicated slashes, slash at end of path, "." or ".." path segments, etc, does not create different g-file objects.

Many g-file operations have both synchronous and asynchronous versions to suit your application. Asynchronous versions of synchronous functions simply have _async appended to their function names. The asynchronous I/O functions call a GAsyncReadyCallback which is then used to finalize the operation, producing a GAsyncResult which is then passed to the matching _finish operation of the functions.

It is highly recommended to use asynchronous calls when running within a shared main loop, such as in the main thread of an application. This avoids I/O operations blocking other sources on the main loop from being dispatched. Synchronous I/O operations should be performed from worker threads. See the introduction to asynchronous programming section for more.

Some g-file operations do not have synchronous analogs, as they may take a very long time to finish, and blocking may leave an application unusable. Notable cases include: the g-file-mount-mountable function to mount a mountable file. The g-file-unmount-mountable-with-operation function to unmount a mountable file. The g-file-eject-mountable-with-operation function to eject a mountable file.

Entity Tags

One notable feature of g-file objects are entity tags, or "etags" for short. Entity tags are somewhat like a more abstract version of the traditional mtime, and can be used to quickly determine if the file has been modified from the version on the file system. See the HTTP 1.1 specification for HTTP Etag headers, which are a very similar concept.