Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to check if directory exists at all? #21

Closed
kornerr opened this issue Jul 23, 2019 · 2 comments
Closed

How to check if directory exists at all? #21

kornerr opened this issue Jul 23, 2019 · 2 comments

Comments

@kornerr
Copy link

kornerr commented Jul 23, 2019

Hi.

There are mkdir, readdir, but the docs don't mention any way to check if directory exists. Is there such a function?

Thanks.

@100ideas
Copy link

100ideas commented Aug 6, 2019

Here's an example: https://github.com/jcubic/fs-browser/blob/master/src/index.js#L63

This code hooks lightning-fs up to a jquery file-browser plugin so ignore those parts.

// https://github.com/jcubic/fs-browser/blob/5730cdb47a34effb41321679c78f687c0c5996ed/src/index.js#L63

    var fs = new LightningFS('fs').promises;
    // facade for RPC service used for editor
    const service = {
        is_writable: function() {
            return Promise.resolve(true);
        },
        file: function(path) {
            return fs.readFile(path, 'utf8');
        },
        filemtime: async function(path) {
            const stat = await fs.stat(path);
            return stat && stat.mtimeMs;
        },
        file_exists: async function(path) {
            try {
                await fs.stat(path);
                return true;
            } catch(e) {
                return false;
            }
        },
        save: function(path, content) {
            return fs.writeFile(path, content);
        }
    };
    var browser = $('<div/>').dialog({
        width: 600,
        height: 480
    }).browse({
        root: '/',
        separator: '/',
        contextmenu: true,
        menu: function(type) {
            if (type == 'li') {
                return {
                    'delete': function($li) {
                        alert(`delete "${ $li.text() }"`);
                    }
                };
            }  else {
                return true;
            }
        },
        dir: async function(path) {
            var names = await fs.readdir(path);
            var result = {files:[], dirs: []};
            for (let name of names) {
                const stat = await fs.stat(path + '/' + name);
                if (stat && stat.isDirectory()) {
                    result.dirs.push(name);
                } else {
                    result.files.push(name);
                }
            }
            return result;
        },
        exists: async function(path) {
            try {
                return await fs.stat(path);
            } catch (e) {
                return false;
            }
        },

@billiegoose
Copy link
Member

billiegoose commented Aug 7, 2019

Yup! Basically what @100ideas said. Here's the version I use in isomorphic-git

https://github.com/isomorphic-git/isomorphic-git/blob/2e6198df39279b3804ef6be7e3801b8a230557db/src/models/FileSystem.js#L60-L77

And yeah. Kinda annoying right, because there's a try/catch and everything? But then I looked at the source code for Node's fs.exists and yeah, it turns out that's how it's done.

https://github.com/nodejs/node/blob/b1e52fe2ea99a52ace6399e9f629c965f66a2643/lib/fs.js#L226-L245

At least until recently. It looks like ~2 years ago Node fs.exists switched from using stat under the hood to using access. I'm not sure how the new one works.

In theory, a native implementation of exists that doesn't throw an Error and immediately catch it might be ever-so-slightly faster. Not sure what the overhead of creating an Error object is... it can be "expensive" because it creates a stack trace - although I think most browsers compute the stack trace only if needed nowadays. Hmm.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants