A wrapper for the POSIX access() function. This function is used to test a pathname for one or several of read, write or execute permissions, or just existence. On Windows, the file protection mechanism is not at all POSIX-like, and the underlying function in the C library only checks the FAT-style READONLY attribute, and does not look at the ACL of a file at all. This function is this in practise almost useless on Windows. Software that needs to handle file permissions on Windows more exactly should use the Win32 API. See your C library manual for more details about access(). Since 2.8
A wrapper for the POSIX chdir() function. The function changes the current directory of the process to path. See your C library manual for more details about chdir(). Since 2.8
A wrapper for the POSIX chmod() function. The chmod() function is used to set the permissions of a file system object. On Windows the file protection mechanism is not at all POSIX-like, and the underlying chmod() function in the C library just sets or clears the FAT-style READONLY attribute. It does not touch any ACL. Software that needs to manage file permissions on Windows exactly should use the Win32 API. See your C library manual for more details about chmod(). Since 2.8
This wraps the close() call; in case of error, errno will be preserved, but the error will also be stored as a GError in error. Besides using GError, there is another major reason to prefer this function over the call provided by the system; on Unix, it will attempt to correctly handle EINTR, which has platform-specific semantics. Since 2.36
A wrapper for the POSIX creat() function. The creat() function is used to convert a pathname into a file descriptor, creating a file if necessary. On POSIX systems file descriptors are implemented by the operating system. On Windows, it's the C library that implements creat() and file descriptors. The actual Windows API for opening files is different, see MSDN documentation for CreateFile(). The Win32 API uses file handles, which are more randomish integers, not small integers like file descriptors. Because file descriptors are specific to the C library on Windows, the file descriptor returned by this function makes sense only to functions in the same C library. Thus if the GLib-using code uses a different C library than GLib does, the file descriptor returned by this function cannot be passed to C library functions like write() or read(). See your C library manual for more details about creat(). Since 2.8
Gets a GFileError constant based on the passed-in err_no. For example, if you pass in EEXIST this function returns G_FILE_ERROR_EXIST. Unlike errno values, you can portably assume that all GFileError values will exist. Normally a GFileError value goes into a GError returned from a function that manipulates files. So you would use g_file_error_from_errno() when constructing a GError.
Reads an entire file into allocated memory, with good error checking. If the call was successful, it returns TRUE and sets contents to the file contents and length to the length of the file contents in bytes. The string stored in contents will be nul-terminated, so for text files you can pass NULL for the length argument. If the call was not successful, it returns FALSE and sets error. The error domain is G_FILE_ERROR. Possible error codes are those in the GFileError enumeration. In the error case, contents is set to NULL and length is set to zero.
Opens a file for writing in the preferred directory for temporary files (as returned by g_get_tmp_dir()). tmpl should be a string in the GLib file name encoding containing a sequence of six 'X' characters, as the parameter to g_mkstemp(). However, unlike these functions, the template should only be a basename, no directory components are allowed. If template is NULL, a default template is used. Note that in contrast to g_mkstemp() (and mkstemp()) tmpl is not modified, and might thus be a read-only literal string. Upon success, and if name_used is non-NULL, the actual name used is returned in name_used. This string should be freed with g_free() when not needed any longer. The returned name is in the GLib file name encoding.
Reads the contents of the symbolic link filename like the POSIX readlink() function. The returned string is in the encoding used for filenames. Use g_filename_to_utf8() to convert it to UTF-8. Since 2.4
Writes all of contents to a file named filename, with good error checking. If a file called filename already exists it will be overwritten. This write is atomic in the sense that it is first written to a temporary Since 2.8
Returns TRUE if any of the tests in the bitfield test are TRUE. For example, (G_FILE_TEST_EXISTS | G_FILE_TEST_IS_DIR) will return TRUE if the file exists; the check whether it's a directory doesn't matter since the existence test is TRUE. With the current set of available tests, there's no point passing in more than one test at a time. Apart from G_FILE_TEST_IS_SYMLINK all tests follow symbolic links, so for a symbolic link to a regular file g_file_test() will return TRUE for both G_FILE_TEST_IS_SYMLINK and G_FILE_TEST_IS_REGULAR. Note, that for a dangling symbolic link g_file_test() will return TRUE for G_FILE_TEST_IS_SYMLINK and FALSE for all other flags. You should never use g_file_test() to test whether it is safe to perform an operation, because there is always the possibility of the condition changing before you actually perform the operation. For example, you might think you could use G_FILE_TEST_IS_SYMLINK to know whether it is safe to write to a file without being tricked into writing into a different location. It doesn't work! Another thing to note is that G_FILE_TEST_EXISTS and G_FILE_TEST_IS_EXECUTABLE are implemented using the access() system call. This usually doesn't matter, but if your program is setuid or setgid it means that these tests will give you the answer for the real user ID and group ID, rather than the effective user ID and group ID. On Windows, there are no symlinks, so testing for G_FILE_TEST_IS_SYMLINK will always return FALSE. Testing for G_FILE_TEST_IS_EXECUTABLE will just check that the file exists and its name indicates that it is executable, checking for well-known extensions and those listed in the PATHEXT environment variable.
A wrapper for the stdio fopen() function. The fopen() function opens a file and associates a new stream with it. Because file descriptors are specific to the C library on Windows, and a file descriptor is partof the FILE struct, the FILE pointer returned by this function makes sense only to functions in the same C library. Thus if the GLib-using code uses a different C library than GLib does, the FILE pointer returned by this function cannot be passed to C library functions like fprintf() or fread(). See your C library manual for more details about fopen(). Since 2.6
A wrapper for the POSIX freopen() function. The freopen() function opens a file and associates it with an existing stream. See your C library manual for more details about freopen(). Since 2.6
A wrapper for the POSIX lstat() function. The lstat() function is like stat() except that in the case of symbolic links, it returns information about the symbolic link itself and not the file that it refers to. If the system does not support symbolic links g_lstat() is identical to g_stat(). See your C library manual for more details about lstat(). Since 2.6
A wrapper for the POSIX mkdir() function. The mkdir() function attempts to create a directory with the given name and permissions. The mode argument is ignored on Windows. See your C library manual for more details about mkdir(). Since 2.6
Create a directory if it doesn't already exist. Create intermediate parent directories as needed, too. Since 2.8
Creates a temporary directory. See the mkdtemp() documentation on most UNIX-like systems. The parameter is a string that should follow the rules for mkdtemp() templates, i.e. contain the string "XXXXXX". g_mkdtemp() is slightly more flexible than mkdtemp() in that the sequence does not have to occur at the very end of the template and you can pass a mode and additional flags. The X string will be modified to form the name of a directory that didn't exist. The string should be in the GLib file name encoding. Most importantly, on Windows it should be in UTF-8. Since 2.30
Creates a temporary directory. See the mkdtemp() documentation on most UNIX-like systems. The parameter is a string that should follow the rules for mkdtemp() templates, i.e. contain the string "XXXXXX". g_mkdtemp() is slightly more flexible than mkdtemp() in that the sequence does not have to occur at the very end of the template and you can pass a mode. The X string will be modified to form the name of a directory that didn't exist. The string should be in the GLib file name encoding. Most importantly, on Windows it should be in UTF-8. Since 2.30
Opens a temporary file. See the mkstemp() documentation on most UNIX-like systems. The parameter is a string that should follow the rules for mkstemp() templates, i.e. contain the string "XXXXXX". g_mkstemp() is slightly more flexible than mkstemp() in that the sequence does not have to occur at the very end of the template. The X string will be modified to form the name of a file that didn't exist. The string should be in the GLib file name encoding. Most importantly, on Windows it should be in UTF-8.
Opens a temporary file. See the mkstemp() documentation on most UNIX-like systems. The parameter is a string that should follow the rules for mkstemp() templates, i.e. contain the string "XXXXXX". g_mkstemp_full() is slightly more flexible than mkstemp() in that the sequence does not have to occur at the very end of the template and you can pass a mode and additional flags. The X string will be modified to form the name of a file that didn't exist. The string should be in the GLib file name encoding. Most importantly, on Windows it should be in UTF-8. Since 2.22
A wrapper for the POSIX open() function. The open() function is used to convert a pathname into a file descriptor. On POSIX systems file descriptors are implemented by the operating system. On Windows, it's the C library that implements open() and file descriptors. The actual Win32 API for opening files is quite different, see MSDN documentation for CreateFile(). The Win32 API uses file handles, which are more randomish integers, not small integers like file descriptors. Because file descriptors are specific to the C library on Windows, the file descriptor returned by this function makes sense only to functions in the same C library. Thus if the GLib-using code uses a different C library than GLib does, the file descriptor returned by this function cannot be passed to C library functions like write() or read(). See your C library manual for more details about open(). Since 2.6
A wrapper for the POSIX remove() function. The remove() function deletes a name from the filesystem. See your C library manual for more details about how remove() works on your system. On Unix, remove() removes also directories, as it calls unlink() for files and rmdir() for directories. On Windows, although remove() in the C library only works for files, this function tries first remove() and then if that fails rmdir(), and thus works for both files and directories. Note however, that on Windows, it is in general not possible to remove a file that is open to some process, or mapped into memory. If this function fails on Windows you can't infer too much from the errno value. rmdir() is tried regardless of what caused remove() to fail. Any errno value set by remove() will be overwritten by that set by rmdir(). Since 2.6
A wrapper for the POSIX rename() function. The rename() function renames a file, moving it between directories if required. See your C library manual for more details about how rename() works on your system. It is not possible in general on Windows to rename a file that is open to some process. Since 2.6
A wrapper for the POSIX rmdir() function. The rmdir() function deletes a directory from the filesystem. See your C library manual for more details about how rmdir() works on your system. Since 2.6
A wrapper for the POSIX stat() function. The stat() function returns information about a file. On Windows the stat() function in the C library checks only the FAT-style READONLY attribute and does not look at the ACL at all. Thus on Windows the protection bits in the st_mode field are a fabrication of little use. On Windows the Microsoft C libraries have several variants of the stat struct and stat() function with names like "stat", "_stat32", "_stat32i64" and "_stat64i32". The one used here is for 32-bit code the one with 32-bit size and time fields, specifically called "_stat32". In Microsoft's compiler, by default "struct stat" means one with 64-bit time fields while in MinGW "struct stat" is the legacy one with 32-bit fields. To hopefully clear up this messs, the gstdio.h header defines a type GStatBuf which is the appropriate struct type depending on the platform and/or compiler being used. On POSIX it is just "struct stat", but note that even on POSIX platforms, "stat" might be a macro. See your C library manual for more details about stat(). Since 2.6
A wrapper for the POSIX unlink() function. The unlink() function deletes a name from the filesystem. If this was the last link to the file and no processes have it opened, the diskspace occupied by the file is freed. See your C library manual for more details about unlink(). Note that on Windows, it is in general not possible to delete files that are open to some process, or mapped into memory. Since 2.6
A wrapper for the POSIX utime() function. The utime() function sets the access and modification timestamps of a file. See your C library manual for more details about how utime() works on your system. Since 2.18
There is a group of functions which wrap the common POSIX functions dealing with filenames (g_open(), g_rename(), g_mkdir(), g_stat(), g_unlink(), g_remove(), g_fopen(), g_freopen()). The point of these wrappers is to make it possible to handle file names with any Unicode characters in them on Windows without having to use ifdefs and the wide character API in the application code.
The pathname argument should be in the GLib file name encoding. On POSIX this is the actual on-disk encoding which might correspond to the locale settings of the process (or the G_FILENAME_ENCODING environment variable), or not.
On Windows the GLib file name encoding is UTF-8. Note that the Microsoft C library does not use UTF-8, but has separate APIs for current system code page and wide characters (UTF-16). The GLib wrappers call the wide character API if present (on modern Windows systems), otherwise convert to/from the system code page.
Another group of functions allows to open and read directories in the GLib file name encoding. These are g_dir_open(), g_dir_read_name(), g_dir_rewind(), g_dir_close().