gripe: deprecating fs.exists/existsSync

After noticing in the node docs that fs.exists and fs.existsSync were going to be deprecated, I took at look at the iojs docs to see that it had in fact been.

This is really annoying and seems like it's based out of the assumption that every developer ever is only checking the existence of a file prior to reading/writing in some async context. While I understand the sentiment behind wanting to avoid 'unnecessary abstractions' or race conditions, this is unnecessary.

Whereas I was previously able to handle the checking of a file's existence with a single boolean variable, I'm now given no other option but to either try/catch or make my code async and listen for error events.

This feels like prescriptivism, as I can't think of a single reason why a stern warning of the potential implications and/or examples of caveats to its use wouldn't have sufficed.

Can anyone help me understand why this was necessary (beyond pushing the all-async-all-the-time paradigm (that doesn't always necessarily apply (particularly in the case of synchronous CLI tooling)))?

Or perhaps can I just submit a PR that un-deprecates this perfectly good functionality?

EDIT: I am happy to provide any additional documentation that is deemed necessary.

This is really annoying and seems like it's based out of the assumption that every developer ever is only checking the existence of a file prior to reading/writing in some async context.

That's not quite how it is.

See fs.exists() in the docs .. it's been replaced by fs.access()

See #114 for more reference.

Reason being: fs.exists() used an API format that was unlike anything else in our API, and could produce results that were unexpected to those who didn't otherwise know.

fs.access doesn't seem like a replacement given that it also throws when there are any accessibility checks that fail. I don't want/need to do error handling every time I check for a file's existence. I don't think it's fair to call this a replacement.

I'm now given no other option but to either try/catch or make my code async and listen for error events.

That would be correct.

OK, close the issue before I can even reply? Awesome!

Deprecation with this kind of logic/motivation is only going to serve to make this platform less hospitable to people doing things outside of what features core is focused on.

I still don't see any reason why thorough documentation isn't an adequate response to any of the concerns that have been mentioned thus far.

I'm also pretty concerned at the realization that this is how we're treating issues created around valid questions/concerns.

Slapping down an open issue within 20 minutes of its creation is pretty hostile.

Original discussion can be found at nodejs/node-v0.x-archive#8418 & #103

Slapping down an open issue within 20 minutes of its creation is pretty hostile.

The GitHub close issue button is in the same location a cancel button usually is. This isn't uncommon for people to occasionally do. Is the intent not clear since I directly re-opened it? :/

If you're concerned about having to do a try-catch everywhere for fs.accessSync(), why not just make your own wrapper function(s)?:

var fs = require('fs');
function existsSync(filename) {
  try {
    fs.accessSync(filename);
    return true;
  } catch(ex) {
    return false;
  }
}
function exists(filename, cb) {
  fs.access(filename, cb);
  // or if want exactly the same old API:
 //fs.access(function(err) { cb(err ? false : true); });
}

or why not leave the wrapper the way it is and let me continue to use fs.existsSync? 😸

perfectly good functionality?

or why not leave the wrapper the way it is and let me continue to use fs.existsSync?

That same thinking can be applied to just adding more and more sugar to core too. There is plenty discussion in the issues I liked above. At minimum, it wasn't particularly perfect, but it wasn't broken either.

Not all flags work on Windows (e.g. O_NOATIME) but most of them do.

It's an undocumented but pretty stable feature. The mode strings themselves are implemented in terms of O_flag constants, e.g., 'a' is shorthand for O_APPEND | O_CREAT | O_WRONLY.

Was just about to open an issue on this. Documentation is unclear about access being a replacement. I think the real issue here is how the not found is communicated. If access/stat are to be used for an existent check, then an exception on not found is too severe. Wouldn't returning that it's not FRWX sufficient?

fs.exists is really necessary. If the api is broken can we fix it rather than deprecate it? Or otherwise, can we provide an option for fs.access, if the second parameter mode === fs.E_OK then do not throw the error and returns the boolean?

@andyhu

@andyhu Once again: fs.exists doesn't do what one might think it's doing judging by its name, and that is a problem.

Just use fs.access as a replacement, it does exactly the same for all fs.exists usecases (except for having the correct callback signature).

Seems at this point the ask is for an API that does:

function doesReallyExistSync(path) {
  try { return !fs.accessSync(path, fs.F_OK) } catch (e) { return false }
}

TBH I understand wanting such a simple API, but the problem is it's not actually that simple. Take the following example where directory b is a symlink back to a:

fs.accessSync('./a' + '/b/a'.repeat(60) + '/c', fs.F_OK)

Which will result in the following:

Error: ELOOP: too many symbolic links encountered, access './a/b/[...]/a/c
    at Error (native)
    at Object.fs.accessSync (fs.js:203:11)

Is node also supposed to add the logic of checking for ELOOP and running the path through fs.realpath() to get around this issue? If so then I'd expect node to do it's best to compensate for any platform specific issues in the API. Here things get a bit hairy, and suddenly an API at first glance was one line becomes more complex. Enough, IMO, to merit its own module (there are commonly used smaller modules out there).

I filed PR #7455 to improve the performance of existsSync beyond what's possible in pure JS (by avoiding throwing an ignored exception).

@trevnorris

@trevnorris Your accessSync example is pretty funky! Luckily, we already know what the right thing to do with that is: existsSync returns false in that case. LGTM, so let's just undeprecate that.

Just for reference I looked up how other languages/runtimes do this:

Python 3 (uses stat, "if stat fails, file is assumed not to exist" -method):

# Does a path exist?
# This is false for dangling symbolic links on systems that support them.
def exists(path):
    """Test whether a path exists.  Returns False for broken symbolic links"""
    try:
        os.stat(path)
    except OSError:
        return False
    return True

Java (JDK 8) (uses stat, "if stat fails, file is assumed not to exist" -method):

JNIEXPORT jint JNICALL
Java_java_io_UnixFileSystem_getBooleanAttributes0(JNIEnv *env, jobject this,
                                                  jobject file)
{
    jint rv = 0;

    WITH_FIELD_PLATFORM_STRING(env, file, ids.path, path) {
        int mode;
        if (statMode(path, &mode)) {
            int fmt = mode & S_IFMT;
            rv = (jint) (java_io_FileSystem_BA_EXISTS
                  | ((fmt == S_IFREG) ? java_io_FileSystem_BA_REGULAR : 0)
                  | ((fmt == S_IFDIR) ? java_io_FileSystem_BA_DIRECTORY : 0));
        }
    } END_PLATFORM_STRING(env, path);
    return rv;
}

Perl (uses stat, -e (exists) op is 1/true if stat has returned any results, false otherwise)

my %op = (
    r => sub { cando($_[0], S_IRUSR, 1) },
    w => sub { cando($_[0], S_IWUSR, 1) },
    x => sub { cando($_[0], S_IXUSR, 1) },
    o => sub { $_[0][4] == $>           },

    R => sub { cando($_[0], S_IRUSR, 0) },
    W => sub { cando($_[0], S_IWUSR, 0) },
    X => sub { cando($_[0], S_IXUSR, 0) },
    O => sub { $_[0][4] == $<           },

    e => sub { 1 }     <--- exists

PHP (uses stat, "if stat fails, file is assumed not to exist" -method):
Snippet from (filestat.c):

/* {{{ proto bool file_exists(string filename)
   Returns true if filename exists */
FileFunction(PHP_FN(file_exists), FS_EXISTS)

...

    case FS_EXISTS:
        RETURN_TRUE;

Go (uses stat with additional library function to test returned error for file existence clues):

if _, err := os.Stat("./thefile.ext"); err != nil {
    if os.IsNotExist(err) {
        // file does not exist
    } else {
        // other error
    }
}

Go language approach is the most interesting: they provide standard stat and then have two separate core library convenience functions for determining if returned error indicates file existence or non-existence os.IsExists(err) and os.IsNotExists(err).

With exception of Go language, most common method for implementing "file exists" test seems to be just running stat and assuming file existence if anything / no error is returned.

@dfabulich

@dfabulich

we already know what the right thing to do with that is: existsSync returns false in that case.

Not exactly. fs.realpath() should resolve the symbolic links to a path that fs.access() can handle (there's a bug in v6 where that doesn't work, for which I'm working on). So if the user got ELOOP they could then call the operation again with fs.access(fs.realpath(path));. Simply returning false would be technically incorrect.

For those interested:

I've published a userland module fs-exists-nodeback

https://github.com/imyller/node-fs-exists-nodeback

When loaded the module polyfills fs.exists to support both original Node.js callback style and standard error first callback style in a backward compatible way.

This may offer solution to those having issues with the callback(boolean) not working with libraries expecting functions with nodeback standard callback.

I think 7b5ffa4 should fix / address this.

It undeprecates existsSync() and keeps the inconsistent-callback exists() deprecated.

fs,doc: undeprecate existsSync

Navigation Menu

Repository navigation

gripe: deprecating fs.exists/existsSync #1592

192 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

gripe: deprecating fs.exists/existsSync #1592

Description

Activity

Fishrock123 commented on May 2, 2015

Fishrock123 commented on May 2, 2015

affinity-matrix commented on May 2, 2015

Fishrock123 commented on May 2, 2015

affinity-matrix commented on May 2, 2015

affinity-matrix commented on May 2, 2015

affinity-matrix commented on May 2, 2015

Fishrock123 commented on May 2, 2015

Fishrock123 commented on May 2, 2015

mscdex commented on May 2, 2015

affinity-matrix commented on May 2, 2015

Fishrock123 commented on May 2, 2015

192 remaining items

bnoordhuis commented on Jun 5, 2016

neuroscr commented on Jun 14, 2016

yf-hk commented on Jun 25, 2016

ChALkeR commented on Jun 25, 2016

trevnorris commented on Jun 27, 2016

dfabulich commented on Jun 28, 2016

dfabulich commented on Jun 28, 2016

imyller commented on Jun 28, 2016

trevnorris commented on Jun 28, 2016

imyller commented on Jul 25, 2016

Fishrock123 commented on Oct 5, 2016

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions