RS just noticed that from Windows 2000 over network boundaries, it may report 1 even for directories where I positively may not write. A hacky workaround seems to be:

 set dummyname $name.[clock seconds] ;# not to clobber an existing one
 if { [catch {file open $dummyname w]} fp] } {
   # not writable
 } else {
   close $fp
   file delete $dummyname
 }

EL confirms this, and notices that the converse is also true: 0 is being returned where I do have permission to write. Also for regular files, [file writable] is unreliable across network boundaries. Richard's hack might be extended to:

 rename file _file
 proc file {args} {
     if {[string match [lindex $args 0]* writable]} {
         set name [lindex $args 1]
         if {[file isdirectory $name]} {
             set fileName [file join $name writabletest.dummy]
             set isdir 1
         } elseif {[file exists $name]} {
             set fileName $name
             set isdir 0
         } else {
             return 0
         }
         if {[catch {open $fileName w} fp]} {
             # not writable
             return 0
         } else {
             close $fp
             if {$isdir} {
                 file delete $fileName
             }
             return 1
         }
     } else {
         eval _file $args
     }
 }

Vince adds --- 'NativeAccess' in tclWinFile.c needs updating to deal with Windows user/permission-related information (whatever that is -- anyone have any pointers?). APN This comment seems outdated as the Tcl source does seem to look at ACL's when deciding on writability. Nevertheless, it has been my experience that the only reliable cross-platform way to check for writability with no false positives and false negatives is to actually try and open the file. Everything else has some failure mode or the other across networked file systems (both Unix and Windows).

LV 2007 Nov 01 So, was a bug report filed at http://tcl.sf.net/ for this problem?

EL would TWAPI be of use here?

See also

• file
• file readable
• file owned