15.2 Filesystem

15.2.1 Locating Paths

• 'home-dir — the current user’s home directory.

  On all platforms, if the PLTUSERHOME environment variable is defined as a complete path, then the path is used as the user’s home directory.

  On Unix and Mac OS, when PLTUSERHOME does not apply, the user’s home directory is determined by expanding the path "~", which is expanded by first checking for a HOME environment variable. If none is defined, the USER and LOGNAME environment variables are consulted (in that order) to find a user name, and then system files are consulted to locate the user’s home directory.

  On Windows, when PLTUSERHOME does not apply, the user’s home directory is the user-specific profile directory as determined by the Windows registry. If the registry cannot provide a directory for some reason, the value of the USERPROFILE environment variable is used instead, as long as it refers to a directory that exists. If USERPROFILE also fails, the directory is the one specified by the HOMEDRIVE and HOMEPATH environment variables. If those environment variables are not defined, or if the indicated directory still does not exist, the directory containing the current executable is used as the home directory.

• 'pref-dir — the standard directory for storing the current user’s preferences. The preferences directory might not exist.

  On Unix, the preferences directory is normally the "racket" subdirectory of the path specified by XDG_CONFIG_HOME, or ".config/racket" in the user’s home directory if XDG_CONFIG_HOME is not set to an absolute path or if PLTUSERHOME is set. Either way, if that directory does not exist but a ".racket" directory exists in the user’s home directory, then that directory is the preference directory, instead.

  On Windows, the preferences directory is "Racket" in the user’s home directory if determined by PLTUSERHOME, otherwise in the user’s application-data folder as specified by the Windows registry; the application-data folder is usually "Application Data" in the user’s profile directory.

  On Mac OS, the preferences directory is "Library/Preferences" in the user’s home directory.

• 'pref-file — a file that contains a symbol-keyed association list of preference values. The file’s directory path always matches the result returned for 'pref-dir. The file name is "racket-prefs.rktd" on Unix and Windows, and it is "org.racket-lang.prefs.rktd" on Mac OS. The file’s directory might not exist. See also get-preference.

• 'temp-dir — the standard directory for storing temporary files. On Unix and Mac OS, this is the directory specified by the TMPDIR environment variable, if it is defined, otherwise it is the first path that exists among "/var/tmp", "/usr/tmp", and "/tmp". On Windows, the result is the directory specified by the TMP or TEMP environment variable, if it is defined, otherwise it is the current directory.

• 'init-dir — the directory containing the initialization file used by the Racket executable.

  On Unix, the initialization directory is the same as the result returned for 'pref-dir—unless that directory does not exist and a ".racketrc" file exists in the user’s home directory, in which case the home directory is the initialization directory.

  On Windows, the initialization directory is the same as the user’s home directory.

  On Mac OS, the initialization directory is "Library/Racket" in the user’s home directory—unless no "racketrc.rktl" exists there and a ".racketrc" file does exist in the home directory, in which case the home directory is the initialization directory.

• 'init-file — the file loaded at start-up by the Racket executable. The directory part of the path is the same path as returned for 'init-dir.

  On Windows, the file part of the name is "racketrc.rktl".

  On Unix and Mac OS, the file part of the name is "racketrc.rktl"—unless the path returned for 'init-dir is the user’s home directory, in which case the file part of the name is ".racketrc".

• 'config-dir — a directory for the installation’s configuration. This directory is specified by the PLTCONFIGDIR environment variable, and it can be overridden by the --config or -G command-line flag. If no environment variable or flag is specified, or if the value is not a legal path name, then this directory defaults to an "etc" directory relative to the current executable. If the result of (find-system-path 'config-dir) is a relative path, it is relative to the current executable. The directory might not exist.

• 'host-config-dir — like 'config-dir, but when cross-platform build mode has been selected (through the -C or --cross argument to racket; see Command Line), the result refers to a directory for the current system’s installation, instead of for the target system.

• 'addon-dir — a directory for user-specific Racket configuration, packages, and extension. This directory is specified by the PLTADDONDIR environment variable, and it can be overridden by the --addon or -A command-line flag. If no environment variable or flag is specified, or if the value is not a legal path name, then this directory defaults to a platform-specific locations. The directory might not exist.

  On Unix, the default is normally the "racket" subdirectory of the path specified by XDG_DATA_HOME, or ".local/share/racket" in the user’s home directory if XDG_CONFIG_HOME is not set to an absolute path or if PLTUSERHOME is set. If that directory does not exists but a ".racket" directory exists in the user’s home directory, that the ".racket" directory path is the default, instead.

  On Windows, the default is the same as the 'pref-dir directory.

  On Mac OS, the default is "Library/Racket" within the user’s home directory.

• 'cache-dir — a directory for storing user-specific caches. The directory might not exist.

  On Unix, the cache directory is normally the "racket" subdirectory of the path specified by XDG_CACHE_HOME, or ".cache/racket" in the user’s home directory if XDG_CACHE_HOME is not set to an absolute path or if PLTUSERHOME is set. If that directory does not exist but a ".racket" directory exists in the home directory, then the ".racket" directory is the cache directory, instead.

  On Windows, the cache directory is the same as the result returned for 'addon-dir.

  On Mac OS, the cache directory is "Library/Caches/Racket" within the user’s home directory.

• 'doc-dir — the standard directory for storing the current user’s documents. On Unix, it’s the user’s home directory. On Windows, it is the user’s home directory if determined by PLTUSERHOME, otherwise it is the user’s documents folder as specified by the Windows registry; the documents folder is usually "My Documents" in the user’s home directory. On Mac OS, it’s the "Documents" directory in the user’s home directory.

• 'desk-dir — the directory for the current user’s desktop. On Unix, it’s the user’s home directory. On Windows, it is the user’s home directory if determined by PLTUSERHOME, otherwise it is the user’s desktop folder as specified by the Windows registry; the desktop folder is usually "Desktop" in the user’s home directory. On Mac OS, it is "Desktop" in the user’s home directory

• 'sys-dir — the directory containing the operating system for Windows. On Unix and Mac OS, the result is "/".

• 'exec-file — the path of the Racket executable as provided by the operating system for the current invocation. For some operating systems, the path can be relative.

  For GRacket, the executable path is the name of a GRacket executable.

• 'run-file — the path of the current executable; this may be different from result for 'exec-file because an alternate path was provided through a --name or -N command-line flag to the Racket (or GRacket) executable, or because an embedding executable installed an alternate path. In particular a “launcher” script created by make-racket-launcher sets this path to the script’s path.

• 'collects-dir — a path to the main collection of libraries (see Libraries and Collections). If this path is relative, then it is relative to the executable as reported by (find-system-path 'exec-file)—though the latter could be a soft-link or relative to the user’s executable search path, so that the two results should be combined with find-executable-path. The 'collects-dir path is normally embedded in the Racket executable, but it can be overridden by the --collects or -X command-line flag.

• 'host-collects-dir — like 'collects-dir, but when cross-platform build mode has been selected (through the -C or --cross argument to racket; see Command Line), the result refers to a directory for the current system’s installation, instead of for the target system. In cross-platform build mode, collection files are normally read from the target system’s installation, but some tasks require current-system directories (such as the one that holds foreign libraries) that are configured relative to the main library-collection path.

• 'orig-dir — the current directory at start-up, which can be useful in converting a relative-path result from (find-system-path 'exec-file) or (find-system-path 'run-file) to a complete path.

Changed in version 6.0.0.3 of package base: Added PLTUSERHOME.
Changed in version 6.9.0.1: Added 'host-config-dir and 'host-collects-dir.
Changed in version 7.8.0.9: Added 'cache-dir, and changed to use XDG directories as preferred on Unix with the previous paths as a fallback, and with similar adjustments for Mac OS.

Changed in version 8.0.0.10 of package base: Changed to allow 'same in default-path-list.

If related is not #f, then it must be a relative path string, and the path found for program must be such that the file or directory related exists in the same directory as the executable. The result is then the full path for the found related, instead of the path for the executable.

This procedure is used by the Racket executable to find the standard library collection directory (see Libraries and Collections). In this case, program is the name used to start Racket and related is "collects". The related argument is used because, on Unix and Mac OS, program may involve a sequence of soft links; in this case, related determines which link in the chain is relevant.

If related is not #f, then when find-executable-path does not find a program that is a link to another file path, the search can continue with the destination of the link. Further links are inspected until related is found or the end of the chain of links is reached. If deepest? is #f (the default), then the result corresponds to the first path in a chain of links for which related is found (and further links are not actually explored); otherwise, the result corresponds to the last link in the chain for which related is found.

If program is a pathless name, find-executable-path gets the value of the PATH environment variable; if this environment variable is defined, find-executable-path tries each path in PATH as a prefix for program using the search algorithm described above for path-containing programs. If the PATH environment variable is not defined, program is prefixed with the current directory and used in the search algorithm above. (On Windows, the current directory is always implicitly the first item in PATH, so find-executable-path checks the current directory first on Windows.)

15.2.2 Files

On Windows, file-exists? reports #t for all variations of the special filenames (e.g., "LPT1", "x:/baddir/LPT1").

The predicates file-exists? or directory-exists? work on the final destination of a link or series of links, while link-exists? only follows links to resolve the base part of path (i.e., everything except the last name in the path).

This procedure never raises the exn:fail:filesystem exception.

On Windows, link-exists? reports #t for both symbolic links and junctions.

Changed in version 6.0.1.12 of package base: Added support for links on Windows.

If path cannot be accessed, the result is #f if must-exist? is #f, otherwise the exn:fail:filesystem exception is raised.

Added in version 7.8.0.5 of package base.

On Windows, if an initial attempt to delete the file fails with a permission error and the value of current-force-delete-permissions is true, then delete-file attempts to change the file’s permissions (to allow writes) and then delete the file; the permission change followed by deletion is a non-atomic sequence, with no attempt to revert a permission change if the deletion fails.

On Windows, delete-file can delete a symbolic link, but not a junction. Use delete-directory to delete a junction.

On Windows, beware that if a file is deleted while it remains in use by some process (e.g., a background search indexer), then the file’s content will eventually go away, but the file’s name remains occupied until the file is no longer used. As long as the name remains occupied, attempts to open, delete, or replace the file will trigger a permission error (as opposed to a file-exists error). A common technique to avoid this pitfall is to move the file to a generated temporary name before deleting it. See also delete-directory/files.

Changed in version 6.1.1.7 of package base: Changed Windows behavior to use current-force-delete-permissions.

This procedure can be used to move a file/directory to a different directory (on the same filesystem) as well as rename a file/directory within a directory. Unless exists-ok? is provided as a true value, new cannot refer to an existing file or directory, but the check is not atomic with the rename operation on Unix and Mac OS. Even if exists-ok? is true, new cannot refer to an existing file when old is a directory, and vice versa.

If new exists and is replaced, the replacement is atomic on Unix and Mac OS, but it is not guaranteed to be atomic on Windows. Furthermore, if new exists and is opened by any process for reading or writing, then attempting to replace it will typically fail on Windows. See also call-with-atomic-output-file.

If old is a link, the link is renamed rather than the destination of the link, and it counts as a file for replacing any existing new.

On Windows, beware that a directory cannot be renamed if any file within the directory is open. That constraint is particularly problematic if a search indexer is running in the background (as in the default Windows configuration). A possible workaround is to combine copy-directory/files and delete-directory/files, since the latter can deal with open files, although that sequence is obviously not atomic and temporarily duplicates files.

For FAT filesystems on Windows, directories do not have modification dates. Therefore, the creation date is returned for a directory, but the modification date is returned for a file.

If secs-n is provided and not #f, the access and modification times of path are set to the given time.

On error (e.g., if no such file exists), then fail-thunk is called (through a tail call) to produce the result of the file-or-directory-modify-seconds call. If fail-thunk is not provided, an error raises exn:fail:filesystem.

If 'bits is supplied as the second argument, the result is a platform-specific integer encoding of the file or directory properties (mostly permissions), and the result is independent of the current user and group. The lowest nine bits of the encoding are somewhat portable, reflecting permissions for the file or directory’s owner, members of the file or directory’s group, or other users:

• #o400 : owner has read permission

• #o200 : owner has write permission

• #o100 : owner has execute permission

• #o040 : group has read permission

• #o020 : group has write permission

• #o010 : group has execute permission

• #o004 : others have read permission

• #o002 : others have write permission

• #o001 : others have execute permission

See also user-read-bit, etc. On Windows, permissions from all three (owner, group, and others) are always the same, and read and execute permission are always available. On Unix and Mac OS, higher bits have a platform-specific meaning.

If an integer is supplied as the second argument, it is used as an encoding of properties (mostly permissions) to install for the file.

In all modes, the exn:fail:filesystem exception is raised on error (e.g., if no such file exists).

If as-link? is a true value, then if path refers to a filesystem link, the identity of the link is returned instead of the identity of the referenced file or directory (if any).

On Windows XP and earlier, the exn:fail:unsupported exception is raised. On later versions of Windows, the creation of links tends to be disallowed by security policies. Windows distinguishes between file and directory links, and a directory link is created only if to parses syntactically as a directory (see path->directory-path). Furthermore, a relative-path link is parsed specially by the operating system; see Windows Paths for more information. When make-file-or-directory-link succeeds, it creates a symbolic link as opposed to a junction or hard link. Beware that directory links must be deleted using delete-directory instead of delete-file.

Changed in version 6.0.1.12 of package base: Added support for links on Windows.

15.2.3 Directories

See also: rename-file-or-directory, file-or-directory-modify-seconds, file-or-directory-permissions.

When the parameter procedure is called to set the current directory, the path argument is cleansed using cleanse-path, simplified using simplify-path, and then converted to a directory path with path->directory-path; cleansing and simplification raise an exception if the path is ill-formed. Thus, the current value of current-directory is always a cleansed, simplified, complete, directory path.

The path is not checked for existence when the parameter is set.

On Unix and Mac OS, the initial value of the parameter for a Racket process is taken from the PWD environment variable—if the value of the environment variable identifies the same directory as the operating system’s report of the current directory.

Normally, current-directory-for-user should stay at its initial value, reflecting the directory where a user started a process. A tool such as DrRacket, however, implicitly lets a user select a directory (for the file being edited), in which case updating current-directory-for-user makes sense.

On Windows, if an initial attempt to delete the directory fails with a permission error and the value of current-force-delete-permissions is true, then delete-file attempts to change the directory’s permissions (to allow writes) and then delete the directory; the permission change followed by deletion is a non-atomic sequence, with no attempt to revert a permission change if the deletion fails.

Changed in version 6.1.1.7 of package base: Changed Windows behavior to use current-force-delete-permissions.

Returns a list of all files and directories in the directory specified by path. If build? is #f, the resulting paths are all path elements; otherwise, the individual results are combined with path using build-path. On Windows, an element of the result list may start with \\?\REL\\.

The resulting paths are always sorted using path<?.

15.2.4 Detecting Filesystem Changes

Many operating systems provide notifications for filesystem changes, and those notifications are reflected in Racket by filesystem change events.

• If path refers to a file, the event becomes ready for synchronization when the file’s content or attributes change, or when the file is deleted.

• If path refers to a directory, the event becomes ready for synchronization if a file or subdirectory is added, renamed, or removed within the directory.

The event also becomes ready for synchronization if it is passed to filesystem-change-evt-cancel.

Finally, depending on the precision of information available from the operating system, the event may become ready for synchronization under other circumstances. For example, on Windows, an event for a file becomes ready when any file changes within in the same directory as the file.

After a filesystem change event becomes ready for synchronization, it stays ready for synchronization. The event’s synchronization result is the event itself.

If the current platform does not support filesystem-change notifications, then the exn:fail:unsupported exception is raised if failure-thunk is not provided as a procedure, or failure-thunk is called in tail position if provided. Similarly, if there is any operating-system error when creating the event (such as a non-existent file), then the exn:fail:filesystem exception is raised or failure-thunk is called.

Creation of a filesystem change event allocates resources at the operating-system level. The resources are released at latest when the event is sychronized and ready for synchronization, when the event is canceled with filesystem-change-evt-cancel, or when the garbage collector determine that the filesystem change event is unreachable. See also system-type in 'fs-change mode.

A filesystem change event is placed under the management of the current custodian when it is created. If the custodian is shut down, filesystem-change-evt-cancel is applied to the event.

Changed in version 7.3.0.8 of package base: Allow #f for failure-thunk.

15.2.5 Declaring Paths Needed at Run Time

The racket/runtime-path library provides forms for accessing files and directories at run time using a path that are usually relative to an enclosing source file. Unlike using collection-path, define-runtime-path exposes each run-time path to tools like the executable and distribution creators, so that files and directories needed at run time are carried along in a distribution.

In addition to the bindings described below, racket/runtime-path provides #%datum in phase level 1, since string constants are often used as compile-time expressions with define-runtime-path.

For run time, id is bound to a path that is based on the result of expr. The path is normally computed by taking a relative path result from expr and adding it to a path for the enclosing file (which is computed as described below). However, tools like the executable creator can also arrange (by colluding with racket/runtime-path) to have a different base path substituted in a generated executable. If expr produces an absolute path, it is normally returned directly, but again may be replaced by an executable creator. In all cases, the executable creator preserves the relative locations of all paths within a given package (treating paths outside of any package as being together). When expr produces a relative or absolute path, then the path bound to id is always an absolute path.

If expr produces a list of the form (list 'lib str ...+), the value bound to id is an absolute path. The path refers to a collection-based file similar to using the value as a module path.

If expr produces a list of the form (list 'so str) or (list 'so str vers), the value bound to id can be either str or an absolute path; it is an absolute path when searching in the Racket-specific shared-object library directories (as determined by get-lib-search-dirs) locates the path. In this way, shared-object libraries that are installed specifically for Racket get carried along in distributions. The search tries each directory in order; within a directory, the search tries using str directly, then it tries adding each version specified by vers—which defaults to '(#f)—along with a platform-specific shared-library extension—as produced by (system-type 'so-suffix). A vers can be a string, or it can be a list of strings and #f.

If expr produces a list of the form (list 'share str), the value bound to id can be either str or an absolute path; it is an absolute path when searching in the directories reported by find-user-share-dir and find-share-dir (in that order) locates the path. In this way, files that are installed in Racket’s "share" directory get carried along in distributions.

If expr produces a list of the form (list 'module module-path var-ref) or (list 'so str (list str-or-false ...)), the value bound to id is a module path index, where module-path is treated as relative (if it is relative) to the module that is the home of the variable reference var-ref, where var-ref can be #f if module-path is absolute. In an executable, the corresponding module is carried along, including all of its dependencies.

For compile-time, the expr result is used by an executable creator—but not the result when the containing module is compiled. Instead, expr is preserved in the module as a compile-time expression (in the sense of begin-for-syntax). Later, at the time that an executable is created, the compile-time portion of the module is executed (again), and the result of expr is the file to be included with the executable. The reason for the extra compile-time execution is that the result of expr might be platform-dependent, so the result should not be stored in the (platform-independent) bytecode form of the module; the platform at executable-creation time, however, is the same as at run time for the executable. Note that expr is still evaluated at run-time; consequently, avoid procedures like collection-path, which depends on the source installation, and instead use relative paths and forms like (list 'lib str ...+).

If a path is needed only on some platforms and not on others, use define-runtime-path-list with an expr that produces an empty list on platforms where the path is not needed.

Beware that define-runtime-path in a phase level other than 0 does not cooperate properly with an executable creator. To work around that limitation, put define-runtime-path in a separate module—perhaps a submodule created by module—then export the definition, and then the module containing the definition can be required into any phase level. Using define-runtime-path in a phase level other than 0 logs a warning at expansion time.

The enclosing path for a define-runtime-path is determined as follows from the define-runtime-path syntactic form:

• If the form has a source module according to syntax-source-module, then the source location is determined by preserving the original expression as a syntax object, extracting its source module path at run time (again using syntax-source-module), and then resolving the resulting module path index. Note that syntax-source-module is based on a syntax object’s lexical information, not its source location.

• If the expression has no source module, the syntax-source location associated with the form is used, if is a string or path.

• If no source module is available, and syntax-source produces no path, then current-load-relative-directory is used if it is not #f. Finally, current-directory is used if all else fails.

In the latter two cases, the path is normally preserved in (platform-specific) byte form, but if the enclosing path corresponds to a result of collection-file-path, then the path is record as relative to the corresponding module path.

Changed in version 6.0.1.6 of package base: Preserve relative paths only within a package.
Changed in version 7.5.0.7: Added support for 'share in expr.

Examples:

; Access a file "data.txt" at run-time that is originally

; located in the same directory as the module source file:

(define-runtime-path data-file "data.txt")

(define (read-data)

(with-input-from-file data-file

(lambda ()

(read-bytes (file-size data-file)))))

; Load a platform-specific shared object (using ffi-lib)

; that is located in a platform-specific sub-directory of the

; module's source directory:

(define-runtime-path libfit-path

(build-path "compiled" "native" (system-library-subpath #f)

(path-replace-suffix "libfit"

(system-type 'so-suffix))))

(define libfit (ffi-lib libfit-path))

; Load a platform-specific shared object that might be installed

; as part of the operating system, or might be installed

; specifically for Racket:

(define-runtime-path libssl-so

(case (system-type)

[(windows) '(so "ssleay32")]

[else '(so "libssl")]))

(define libssl (ffi-lib libssl-so))

Changed in version 6.4 of package base: Added #:runtime?-id.

Use define-runtime-module-path-index to bind a module path that is passed to a reflective function like dynamic-require while also creating a module dependency for building and distributing executables.

The define-runtime-module-path-index form is usually preferred, because it creates a weaker link to the referenced module. Unlike define-runtime-module-path-index, the define-runtime-module-path form creates a for-label dependency from an enclosing module to module-path. Since the dependency is merely for-label, module-path is not instantiated or visited when the enclosing module is instantiated or visited (unless such a dependency is created by other requires), but the code for the referenced module is loaded when the enclosing module is loaded.

15.2.6 More File and Directory Utilities

If keep-modify-seconds? is #f, then file copies keep only the properties kept by copy-file. If keep-modify-seconds? is true, then each file copy also keeps the modification date of the original.

Changed in version 6.3 of package base: Added the #:preserve-links? argument.

If must-exist? is true, then exn:fail:filesystem is raised if path does not exist. If must-exist? is false, then delete-directory/files succeeds if path does not exist (but a failure is possible if path initially exists and is removed by another thread or process before delete-directory/files deletes it).

On Windows, delete-directory/files attempts to move a file into the temporary-file directory before deleting it, which avoids problems caused by deleting a file that is currently open (e.g., by a search indexer running as a background process). If the move attempt fails (e.g., because the temporary directory is on a different drive than the file), then the file is deleted directly with delete-file.

Changed in version 7.0 of package base: Added Windows-specific file deletion.

The predicate procedure is called with a single argument for each file or directory. If start-path is #f, the argument is a pathname string that is relative to the current directory. Otherwise, it is a path building on start-path. Consequently, supplying (current-directory) for start-path is different from supplying #f, because predicate receives complete paths in the former case and relative paths in the latter. Another difference is that predicate is not called for the current directory when start-path is #f.

If skip-filtered-directory? is true, then when predicate returns #f for a directory, the directory’s content is not traversed.

If follow-links? is true, the find-files traversal follows links, and links are not included in the result. If follow-links? is #f, then links are not followed, and links are included in the result.

If start-path does not refer to an existing file or directory, then predicate will be called exactly once with start-path as the argument.

The find-files procedure raises an exception if it encounters a directory for which directory-list fails.

Changed in version 6.3.0.11 of package base: Added the #:skip-filtered-directory? argument.

• if a nested path is given, all of its ancestors are also included in the result (but the same ancestor is not added twice);

• if a path refers to directory, all of its descendants are also included in the result, except as omitted by path-filter;

• ancestor directories appear before their descendants in the result list, as long as they are not misordered in the given path-list.

If path-filter is a procedure, then it is applied to each descendant of a directory. If path-filter returns #f, then the descendant (and any of its descendants, in the case of a subdirectory) are omitted from the result.

If follow-links? is true, then the traversal of directories and files follows links, and the link paths are not included in the result. If follow-links? is #f, then the result list includes paths to link and the links are not followed.

Changed in version 6.3.0.11 of package base: Added the #:path-filter argument.

The proc procedure is called with three arguments for each file, directory, or link:

• If start-path is #f, the first argument is a pathname string that is relative to the current directory. Otherwise, the first argument is a pathname that starts with start-path. Consequently, supplying (current-directory) for start-path is different from supplying #f, because proc receives complete paths in the former case and relative paths in the latter. Another difference is that proc is not called for the current directory when start-path is #f.

• The second argument is a symbol, either 'file, 'dir, or 'link. The second argument can be 'link when follow-links? is #f, in which case the filesystem traversal does not follow links. If follow-links? is #t, then proc will only get a 'link as a second argument when it encounters a dangling symbolic link (one that does not resolve to an existing file or directory).

• The third argument is the accumulated result. For the first call to proc, the third argument is init-val. For the second call to proc (if any), the third argument is the result from the first call, and so on. The result of the last call to proc is the result of fold-files.

The proc argument is used in an analogous way to the procedure argument of foldl, where its result is used as the new accumulated result. There is an exception for the case of a directory (when the second argument is 'dir): in this case the procedure may return two values, the second indicating whether the recursive scan should include the given directory or not. If it returns a single value, the directory is scanned. In the cases of files or links (when the second argument is 'file or 'link), a second value is permitted but ignored.

If the start-path is provided but no such path exists, or if paths disappear during the scan, then an exception is raised.

If path is a relative path and the current directory does not exist, then make-directory* will not create the current directory, because it considers only explicit elements of path.

If path is a filesystem root or a relative path with a single path element, then no directory is created. Like make-directory*, if path is a relative path and the current directory does not exist, then make-parent-directory* will not create it.

Added in version 6.1.1.3 of package base.

The template argument must be a format string suitable for use with format and one additional string argument (where the string contains only digits). If the resulting string is a relative path, it is combined with the result of (find-system-path 'temp-dir), unless directory is provided and non-#f, in which case the file name generated from template is combined with directory to obtain a full path.

The template argument’s default is only the string "rkttmp~a" when there is no source location information for the callsite of make-temporary-file (or if make-temporary-file is used in a higher-order position). If there is such information, then the template string is based on the source location.

If copy-from-filename is provided as path, the temporary file is created as a copy of the named file (using copy-file). If copy-from-filename is #f, the temporary file is created as empty. If copy-from-filename is 'directory, then the temporary “file” is created as a directory.

When a temporary file is created, it is not opened for reading or writing when the pathname is returned. The client program calling make-temporary-file is expected to open the file with the desired access and flags (probably using the 'truncate flag; see open-output-file) and to delete it when it is no longer needed.

The proc function is called with an output port for the temporary file, plus the path of the temporary file. The result of proc is the result of call-with-atomic-output-file.

The call-with-atomic-output-file function arranges to delete temporary files on exceptions.

Windows prevents programs from deleting or replacing files that are open, but it allows renaming of open files. Therefore, on Windows, call-with-atomic-output-file by default creates a second temporary file extra-tmp-file, renames file to extra-tmp-file, renames the temporary file written by proc to file, and finally deletes extra-tmp-file. Since that process is not atomic, however, rename-file-or-directory is used if rename-fail-handler is provided, where rename-file-or-directory has some chance of being atomic, since that the source and destination of the moves will be in the same directory; any filesystem exception while attempting to rename the file is send to rename-fail-handler, which can re-raise the exception or simply return to try again, perhaps after a delay. In addition to a filesystem exception, the rename-fail-handler procedure also receives the temporary file path to be moved to path. The rename-fail-handler argument is used only on Windows.

Changed in version 7.1.0.6 of package base: Added the #:rename-fail-handler argument.

The preference file should contain a list of symbol–value lists written with the default parameter settings. Keys starting with racket:, mzscheme:, mred:, and plt: in any letter case are reserved for use by Racket implementors. If the preference file does not contain a list of symbol–value lists, an error is logged via log-error and failure-thunk is called.

The result of get-preference is the value associated with name if it exists in the association list, or the result of calling failure-thunk otherwise.

Preference settings are cached (weakly) across calls to get-preference, using (path->complete-path filename) as a cache key. If flush-mode is provided as #f, the cache is used instead of re-consulting the preferences file. If flush-mode is provided as 'timestamp (the default), then the cache is used only if the file has a timestamp that is the same as the last time the file was read. Otherwise, the file is re-consulted.

On platforms for which preferences-lock-file-mode returns 'file-lock and when use-lock? is true, preference-file reading is guarded by a lock; multiple readers can share the lock, but writers take the lock exclusively. If the preferences file cannot be read because the lock is unavailable, lock-there is called on the path of the lock file; if lock-there is #f, an exception is raised. The default lock-there handler retries about 5 times (with increasing delays between each attempt) before trying timeout-lock-there, and the default timeout-lock-there triggers an exception.

See also put-preferences. For a more elaborate preference system, see preferences:get.

Old preferences files: When a filename is not provided and the file indicated by (find-system-path 'pref-file) does not exist, the following paths are checked for compatibility with old versions of Racket:

• Windows: (build-path (find-system-path 'pref-dir) 'up "PLT Scheme" "plt-prefs.ss")

• Mac OS: (build-path (find-system-path 'pref-dir) "org.plt-scheme.prefs.ss")

• Unix: (expand-user-path "~/.plt-scheme/plt-prefs.ss")

The names argument supplies the preference names, and vals must have the same length as names. Each element of vals must be an instance of a built-in data type whose write output is readable (i.e., the print-unreadable parameter is set to #f while writing preferences).

Current preference values are read from the preference file before updating, and a write lock is held starting before the file read, and lasting until after the preferences file is updated. The lock is implemented by the existence of a file in the same directory as the preference file; see preferences-lock-file-mode for more information. If the directory of the preferences file does not already exist, it is created.

If the write lock is already held, then locked-proc is called with a single argument: the path of the lock file. The default locked-proc (used when the locked-proc argument is #f) reports an error; an alternative thunk might wait a while and try again, or give the user the choice to delete the lock file (in case a previous update attempt encountered disaster and locks are implemented by the presence of the lock file).

If filename is #f or not supplied, and the preference file does not already exist, then values read from the "defaults" collection (if any) are written for preferences that are not mentioned in names.

The 'exists mode is currently used on all platforms except Windows. In 'exists mode, the existence of the lock file indicates that a write lock is held, and readers need no lock (because the preferences file is atomically updated via rename-file-or-directory).

The 'file-lock mode is currently used on Windows. In 'file-lock mode, shared and exclusive locks (in the sense of port-try-file-lock?) on the lock file reflect reader and writer locks on the preference-file content. (The preference file itself is not locked, because a lock would interfere with replacing the file via rename-file-or-directory.)

Before calling get-preference, the result procedure uses (sleep delay) to pause. Then, if (* 2 delay) is less than max-delay, the result procedure calls make-handle-get-preference-locked to generate a new retry procedure to pass to get-preference, but with a delay of (* 2 delay). If (* 2 delay) is not less than max-delay, then get-preference is called with the given lock-there, instead.

When thunk returns, call-with-file-lock/timeout releases the lock, returning the result of thunk. The call-with-file-lock/timeout function will retry after delay seconds and continue retrying with exponential backoff until delay reaches max-delay. If call-with-file-lock/timeout fails to obtain the lock, failure-thunk is called in tail position. The kind argument specifies whether the lock is 'shared or 'exclusive in the sense of port-try-file-lock?.