4.36 File System Interaction
All Application Manual Name SummaryHelp

  • Documentation
    • Reference manual
      • Built-in Predicates
        • File System Interaction
          • access_file/2
          • exists_file/1
          • file_directory_name/2
          • file_base_name/2
          • same_file/2
          • exists_directory/1
          • delete_file/1
          • rename_file/2
          • size_file/2
          • time_file/2
          • absolute_file_name/2
          • absolute_file_name/3
          • is_absolute_file_name/1
          • file_name_extension/3
          • directory_files/2
          • expand_file_name/2
          • prolog_to_os_filename/2
          • read_link/3
          • tmp_file/2
          • tmp_file_stream/3
          • make_directory/1
          • delete_directory/1
          • working_directory/2
          • chdir/1
    • Packages
Availability:built-in
access_file(+File, +Mode)
True if File exists and can be accessed by this Prolog process under mode Mode. Mode is one of the atoms read, write, append, execute, search, exist, or none. Fails silently otherwise. File may also be the name of a directory. access_file(File, none) simply succeeds without testing anything.

If Mode is write or append, this predicate also succeeds if the file does not exist and the user has write access to the directory of the specified location.

The mode execute is only intended for use with regular files and the mode search only with directories. However, the two modes are currently equivalent and both can be used with either files or directories. This may change in the future, so the results of checking execute access on directories or search access on regular files should not be relied on.

The behaviour is backed up by the POSIX access() API. The Windows replacement (_waccess()) returns incorrect results because it does not consider ACLs (Access Control Lists). The Prolog flag win_file_access_check may be used to control the level of checking performed by Prolog. Please note that checking access never provides a guarantee that a subsequent open succeeds without errors due to inherent concurrency in file operations. It is generally more robust to try and open the file and handle possible exceptions. See open/4 and catch/3.