- 
          
- 
                Notifications
    You must be signed in to change notification settings 
- Fork 7.3k
fs: add access() and accessSync() #8714
Conversation
        
          
                doc/api/fs.markdown
              
                Outdated
          
        
      There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would just say "fs.exists() will be deprecated." since we don't recommend using anything to check for a file exists then blindly reading from it (which is how fs.exists() is being used).
| Awesome stuff. Thanks for getting this in all the way from libuv to here. Just a few comments, but LGTM. | 
| 
 Good point. There are a couple different ways this could work. Honestly there wouldn't have to be a return value at all, since if everything is fine then no error object will exist. e.g. fs.access('/some/thing', function(er) {
  if (!er) {
    // The access check must have succeeded.
  }
});And for  Though this type of API change might be drastic. I definitely like that it'll return a useful error (e.g.  | 
| @trevnorris updated based on your comments. | 
fs.exists() and fs.existsSync() do not follow the typical error first callback convention. access() and accessSync() are added as alternatives in this commit. Fixes: nodejs/node-v0.x-archive#8714 PR-URL: #114 Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Domenic Denicola <[email protected]>
fs.exists() and fs.existsSync() do not follow the typical error first callback convention. access() and accessSync() are added as alternatives in this commit.
| bump. | 
| Thanks for the bump. Landed in 2944934. | 
fs.exists() and fs.existsSync() do not follow the typical error first callback convention. access() and accessSync() are added as alternatives in this commit. PR-URL: #8714 Reviewed-by: Trevor Norris <[email protected]>
fs.exists()andfs.existsSync()do not follow typical node conventions.access()andaccessSync()are added as alternatives in this commit.@trevnorris I opened this as a separate PR because it was decided in #8418 that
exists()andexistsSync()would not be deprecated yet. One thought that I had is that these functions might seem less C-like if they returnedtrueon success instead of the 0 returned by libuv. Thoughts?