gio.file.File is a high level abstraction for manipulating files on a
virtual file system. gio.file.Files are lightweight, immutable objects
that do no I/O upon creation. It is necessary to understand that
gio.file.File objects do not represent files, merely an identifier for a
file. All file content I/O is implemented as streaming operations
(see gio.input_stream.InputStream and gio.output_stream.OutputStream).
One way to think of a gio.file.File is as an abstraction of a pathname. For
normal files the system pathname is what is stored internally, but as
gio.file.Files are extensible it could also be something else that corresponds
to a pathname in a userspace implementation of a filesystem.
All gio.file.Files have a basename (get with gio.file.File.getBasename). 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
G_FILE_ATTRIBUTE_STANDARD_DISPLAY_NAME attribute with
gio.file.File.queryInfo. This is guaranteed to be in UTF-8 and can be
used in a user interface. But always store the real basename or the gio.file.File
to use to actually access the file, because there is no way to go from a
display name to the actual name.
Using gio.file.File 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 gio.file.Files 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 gio.file.Files point to the same file you can query for the
G_FILE_ATTRIBUTE_ID_FILE attribute. Note that gio.file.File 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 gio.file.Files.
Many gio.file.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 gio.types.AsyncReadyCallback which is then used to
finalize the operation, producing a gio.async_result.AsyncResult which is then
passed to the function’s matching _finish() operation.
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 gio.file.File operations almost always take a noticeable amount of time, and
so do not have synchronous analogs. Notable cases include:
One notable feature of gio.file.Files 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.
gio.file.File is a high level abstraction for manipulating files on a virtual file system. gio.file.Files are lightweight, immutable objects that do no I/O upon creation. It is necessary to understand that gio.file.File objects do not represent files, merely an identifier for a file. All file content I/O is implemented as streaming operations (see gio.input_stream.InputStream and gio.output_stream.OutputStream).
To construct a gio.file.File, you can use:
One way to think of a gio.file.File is as an abstraction of a pathname. For normal files the system pathname is what is stored internally, but as gio.file.Files are extensible it could also be something else that corresponds to a pathname in a userspace implementation of a filesystem.
gio.file.Files make up hierarchies of directories and files that correspond to the files on a filesystem. You can move through the file system with gio.file.File using gio.file.File.getParent to get an identifier for the parent directory, gio.file.File.getChild to get a child within a directory, and gio.file.File.resolveRelativePath to resolve a relative path between two gio.file.Files. There can be multiple hierarchies, so you may not end up at the same root if you repeatedly call gio.file.File.getParent on two different files.
All gio.file.Files have a basename (get with gio.file.File.getBasename). 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 G_FILE_ATTRIBUTE_STANDARD_DISPLAY_NAME attribute with gio.file.File.queryInfo. This is guaranteed to be in UTF-8 and can be used in a user interface. But always store the real basename or the gio.file.File to use to actually access the file, because there is no way to go from a display name to the actual name.
Using gio.file.File 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 gio.file.Files 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 gio.file.Files point to the same file you can query for the G_FILE_ATTRIBUTE_ID_FILE attribute. Note that gio.file.File 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 gio.file.Files.
Many gio.file.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 gio.types.AsyncReadyCallback which is then used to finalize the operation, producing a gio.async_result.AsyncResult which is then passed to the function’s matching _finish() operation.
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 gio.file.File operations almost always take a noticeable amount of time, and so do not have synchronous analogs. Notable cases include:
Entity Tags
One notable feature of gio.file.Files 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.