Test file permissions in Windows

Question

The file-writable-p docstring says:

Return t if file FILENAME can be written or created by you.

In Windows you cannot usually write on files when they are used by a different app. In these instances you get a permission denied error since the process blocks the access.

For example, in most of the viewers, if you open ~/foo.pdf, you cannot write access to it. However:

(file-writable-p "~/foo.pdf")

still returns t. Therefore, with ~/foo.pdf open,

(if (file-writable-p "~/foo.pdf")
    (with-temp-file "~/foo.pdf" (insert "Hello World")))

returns the error: (file-error "Opening output file" "Permission denied" ..... The same happens with:

(if (file-writable-p "~/foo.pdf")
    (delete-file "~/foo.pdf"))

Is this the way file-writable-p is intended to work?
If so, which is the proper path to safely write some output to a file?

Answer 1

A version of file-writable-p which returns nil if a Windows process is blocking write access.

(defun file-unblocked-p (filename)
  "This function works similarly to `file-writable-p' but is  with Windows permission denied errors. Therefore it returns nil if another process is blocking write access."  

  (if (not (file-exists-p filename))
      (file-writable-p filename)
    (not (condition-case err
             (rename-file filename filename)        
           (error err)))))

Note: I have tested it on Windows only.

Use this function wisely. In the generality of cases:

(if (file-unblocked-p "~/foo.pdf")
    (delete-file "~/foo.pdf"))

should work, but it is always possible that the writable condition holds when you test it and does not when you actually delete (write) the file. It could be pretty rare, but that depends on your specific use case. If one wants to be absolutely sure to avoid race conditions, one could just write and then check for errors:

(not (condition-case err
     (delete-file filename)        
       (error err)))