Detailed Description

This class serves two purposes: first, it provides the functions to split the file names into components and to recombine these components in the full file name which can then be passed to the OS file functions (and wxWidgets functions wrapping them). Second, it includes the functions for working with the files itself. Note that to change the file data you should use wxFile class instead. wxFileName provides functions for working with the file attributes.

When working with directory names (i.e. without filename and extension) make sure not to misuse the file name part of this class with the last directory. Instead initialize the wxFileName instance like this:

If it is not known whether a string contains a directory name or a complete file name (such as when interpreting user input) you need to use the static function wxFileName::DirExists() (or its identical variants wxDir::Exists() and wxDirExists()) and construct the wxFileName instance accordingly. This will only work if the directory actually exists, of course:

Please note that many wxFileName methods accept the path format argument which is by wxPATH_NATIVE by default meaning to use the path format native for the current platform. The path format affects the operation of wxFileName functions in several ways: first and foremost, it defines the path separator character to use, but it also affects other things such as whether the path has the drive part or not. See wxPathFormat for more info.

File name format

wxFileName currently supports the file names in the Unix, DOS/Windows, Mac OS and VMS formats. Although these formats are quite different, wxFileName tries to treat them all in the same generic way. It supposes that all file names consist of the following parts: the volume (also known as drive under Windows or device under VMS), the path which is a sequence of directory names separated by the path separators and the full filename itself which, in turn, is composed from the base file name and the extension. All of the individual components of the file name may be empty and, for example, the volume name is always empty under Unix, but if they are all empty simultaneously, the filename object is considered to be in an invalid state and wxFileName::IsOk() returns false for it.

You can initialize a wxFileName instance using one of the following functions:

File name operations

These methods allow to work with the file creation, access and modification times. Note that not all filesystems under all platforms implement these times in the same way. For example, the access time under Windows has a resolution of one day (so it is really the access date and not time). The access time may be updated when the file is executed or not depending on the platform.

If the path contains the value of the environment variable named envname then this function replaces it with the string obtained from wxString::Format(replacementFmtString, value_of_envname_variable). More...

Member Function Documentation

This component should contain a single directory name level, i.e. not contain any path or volume separators nor should it be empty, otherwise the function does nothing and returns false (and generates an assert failure in debug build).

Notice that the return value is only available in wxWidgets 2.9.5 or later.

If prefix is an absolute path and ends in a separator, the temporary file is created in this directory; if it is an absolute filepath or there is no separator, the temporary file is created in its path, with the 'name' segment prepended to the temporary filename; otherwise it is created in the default system directory for temporary files or in the current directory.

If the function succeeds, the temporary file is actually created. If fileTemp is not NULL, this wxFile will be opened using the name of the temporary file. Where possible this is done in an atomic way to ensure that no race condition occurs between creating the temporary file name and opening it, which might lead to a security compromise on multiuser systems. If fileTemp is NULL, the file is created but not opened. Under Unix, the temporary file will have read and write permissions for the owner only, to minimize security problems.

Parameters

prefix

Location to use for the temporary file name construction. If prefix is a directory it must have a terminal separator

Returns the object corresponding to the directory with the given name.

The dir parameter may have trailing path separator or not.

void wxFileName::DontFollowLink

(

)

Turns off symlink dereferencing.

By default, all operations in this class work on the target of a symbolic link (symlink) if the path of the file is actually a symlink. Using this method allows to turn off this "symlink following" behaviour and apply the operations to this path itself, even if it is a symlink.

under Windows, but under Unix it also returns true if the file identifies a special file system object such as a device, a socket or a FIFO.

Alternatively you may check for the existence of a file system entry of a specific type by passing the appropriate flags (this parameter is new since wxWidgets 2.9.5). E.g. to test for a symbolic link existence you could use wxFILE_EXISTS_SYMLINK.

In the first version, the size of this file is used. In the second one, the specified size bytes is used.

If the file size could not be retrieved or bytes is wxInvalidSize or zero, the failmsg string is returned.

Otherwise the returned string is a floating-point number with precision decimal digits followed by the abbreviation of the unit used. By default the traditional, although incorrect, convention of using SI units for multiples of 1024 is used, i.e. returned string will use suffixes of B, KB, MB, GB, TB for bytes, kilobytes, megabytes, gigabytes and terabytes respectively. With the IEC convention the names of the units are changed to B, KiB, MiB, GiB and TiB for bytes, kibibytes, mebibytes, gibibytes and tebibytes. Finally, with SI convention the same B, KB, MB, GB and TB suffixes are used but in their correct SI meaning, i.e. as multiples of 1000 and not 1024.

Support for the different size conventions is new in wxWidgets 2.9.1, in previous versions only the traditional convention was implemented.

In the first version, the size of this file is used. In the second one, the specified size bytes is used.

If the file size could not be retrieved or bytes is wxInvalidSize or zero, the failmsg string is returned.

Otherwise the returned string is a floating-point number with precision decimal digits followed by the abbreviation of the unit used. By default the traditional, although incorrect, convention of using SI units for multiples of 1024 is used, i.e. returned string will use suffixes of B, KB, MB, GB, TB for bytes, kilobytes, megabytes, gigabytes and terabytes respectively. With the IEC convention the names of the units are changed to B, KiB, MiB, GiB and TiB for bytes, kibibytes, mebibytes, gibibytes and tebibytes. Finally, with SI convention the same B, KB, MB, GB and TB suffixes are used but in their correct SI meaning, i.e. as multiples of 1000 and not 1024.

Support for the different size conventions is new in wxWidgets 2.9.1, in previous versions only the traditional convention was implemented.

The last access time is updated whenever the file is read or written (or executed in the case of Windows), last modification time is only changed when the file is written to. Finally, the creation time is indeed the time when the file was created under Windows and the inode change time under Unix (as it is impossible to retrieve the real file creation time there anyhow) which can also be changed by many operations after the file creation.

If no filename or extension is specified in this instance of wxFileName (and therefore IsDir() returns true) then this function will return the directory times of the path specified by GetPath(), otherwise the file times of the file specified by GetFullPath(). Any of the pointers may be NULL if the corresponding time is not needed.

With the default flags value, the path will be made absolute, without any ".." and "." and all environment variables will be expanded in it.

Notice that in some rare cases normalizing a valid path may result in an invalid wxFileName object. E.g. normalizing "./" path using wxPATH_NORM_DOTS but not wxPATH_NORM_ABSOLUTE will result in a completely empty and thus invalid object. As long as there is a non empty file name the result of normalization will be valid however.

Parameters

flags

The kind of normalization to do with the file name. It can be any or-combination of the wxPathNormalize enumeration values.

cwd

If not empty, this directory will be used instead of current working directory in normalization (see wxPATH_NORM_ABSOLUTE).

format

The file name format to use when processing the paths, native by default.

If the path contains the value of the environment variable named envname then this function replaces it with the string obtained from wxString::Format(replacementFmtString, value_of_envname_variable).

This function is useful to make the path shorter or to make it dependent from a certain environment variable. Normalize() with wxPATH_NORM_ENV_VARS can perform the opposite of this function (depending on the value of replacementFmtString).

This function splits a full file name into components: the volume (with the first version) path (including the volume in the second version), the base name and the extension.

Any of the output parameters (volume, path, name or ext) may be NULL if you are not interested in the value of a particular component. Also, fullpath may be empty on entry. On return, path contains the file path (without the trailing separator), name contains the file name and ext contains the file extension without leading dot. All three of them may be empty if the corresponding component is. The old contents of the strings pointed to by these parameters will be overwritten in any case (if the pointers are not NULL).

Note that for a filename "foo." the extension is present, as indicated by the trailing dot, but empty. If you need to cope with such cases, you should use hasExt instead of relying on testing whether ext is empty or not.

This function splits a full file name into components: the volume (with the first version) path (including the volume in the second version), the base name and the extension.

Any of the output parameters (volume, path, name or ext) may be NULL if you are not interested in the value of a particular component. Also, fullpath may be empty on entry. On return, path contains the file path (without the trailing separator), name contains the file name and ext contains the file extension without leading dot. All three of them may be empty if the corresponding component is. The old contents of the strings pointed to by these parameters will be overwritten in any case (if the pointers are not NULL).

Note that for a filename "foo." the extension is present, as indicated by the trailing dot, but empty. If you need to cope with such cases, you should use hasExt instead of relying on testing whether ext is empty or not.

This function splits a full file name into components: the volume (with the first version) path (including the volume in the second version), the base name and the extension.

Any of the output parameters (volume, path, name or ext) may be NULL if you are not interested in the value of a particular component. Also, fullpath may be empty on entry. On return, path contains the file path (without the trailing separator), name contains the file name and ext contains the file extension without leading dot. All three of them may be empty if the corresponding component is. The old contents of the strings pointed to by these parameters will be overwritten in any case (if the pointers are not NULL).

Note that for a filename "foo." the extension is present, as indicated by the trailing dot, but empty. If you need to cope with such cases, you should use hasExt instead of relying on testing whether ext is empty or not.

This function does more than just removing everything after the last period from the string, for example it will return the string ".vimrc" unchanged because the part after the period is not an extension but the file name in this case. You can use wxString::BeforeLast() to really get just the part before the last period (but notice that that function returns empty string if period is not present at all unlike this function which returns the fullname unchanged in this case).