Issue with watching directory with name including glob characters

[bpasero]

• have a folder "foo*" (extra star at the end)
• try to watch it with chokidar
  => it will not work because foo* is treated as glob pattern

How is it possible to use a path "as is" without glob smartness?

[es128]

There is no option to disable glob matching.

For filenames that use glob characters it should work as that issue has been reported in the past (by you iirc) and fixed.

It may be necessary to look into a similar fix for directory names.

However, I'm not sure why the example you've provided wouldn't already work. foo* as a glob pattern should match foo* as a directory name. Unless the issue is that it's also matching the foobar directory and you don't want that.

[bpasero]

Yes, this is an issue for folders I want to watch on that contain glob
sensitive characters.
Am 04.06.2015 2:51 nachm. schrieb "Elan Shanker" notifications@github.com:

There is no option to disable glob matching.

For filenames that use glob characters it should work as that issue has
been reported in the past (by you iirc) and fixed.

It may be necessary to look into a similar fix for directory names.

However, I'm not sure why the example you've provided wouldn't already
work. foo* as a glob pattern should match foo* as a directory name.
Unless the issue is that it's also matching the foobar directory and you
don't want that.

—
Reply to this email directly or view it on GitHub
#300 (comment).

[es128]

Can you provide a more realistic example?

[bpasero]

Wait, what? How can you say a valid folder name which chokidar cannot watch is not a realistic example :)?

[es128]

I'm saying that given foo* as a path to watch chokidar would watch a directory named foo* since that matches the glob pattern.

This wouldn't be the case for any glob-like name, so I'm interested in your actual example.

[bpasero]

Hm, I was running an example on my Mac with latest chokidar watching a folder foo* that was actually on disk (~/Desktop/foo*) and I did not receive file events. I can try again later when I am back at my Mac to post a snippet here, but I thought the issue was more obvious.

[bpasero]

@es128 Here are the steps:

• have a folder on the desktop called bar with a folder called foo*
• run following code
• drop a file into the folder foo*
• you dont see an output for the event

var chokidar = require("chokidar");

var watcher = chokidar.watch('/Users/<name>/Desktop/bar/foo*');
watcher.on("all", function(event, path) {
    console.log(event, path);
});

[paulmillr]

The question here is: the foo* folder name is an actual real-world case in your project(s) or it's just a scenario?

[bpasero]

The folder in question was "js* - rewrite" by a colleague of mine using Visual Studio Code, complaining file events do not work. So yeah, this is real!

[ArtemGovorov]

We have hit the same issue in wallaby.js. Here is what we do:

let Watcher = require('chokidar').FSWatcher;
let watcher = new Watcher({ cwd: '/downloads/project (1)' });
watcher.add('test/**/*.js');
watcher.on('add', p => console.log(p));

So while watcher.add('test/**/*.js'); is totally expected to accept glob patterns, cwd in our case is a project root, for example an unzipped project archive downloaded from GitHub. When a user downloads something multiple times, he may end up having project (1), project (2), etc. folders named automatically. If it's not possible or hard to make an option to use all paths without glob smartness, then at least the cwd part should not be treated as a glob pattern. Does it make sense?

[tonypee]

I have the same issue with brackets /Dropbox/Photos (Tony)/ - this is very common i'd think

[DmitryKon]

I have the same issue with watching a folder containing '!' character, for example 'c:\Works!tests' - changes for files in such folder are not watched.

Is there any workaround for this (except renaming the folder)?

[sashashakun]

Hi all, I want to help with this issue, will try to reproduce mentioned cases and return with results in few days:)

[sashashakun]

Meh, too busy, take a pause with this(

[Torvin]

C'mon! If you claim to support glob syntax, support escaping too.Or at least add an option to disable globs.

[paulmillr]

Agree.

[bpasero]

@es128 @paulmillr can you point me to the location in code where a folder is being treated as glob pattern when found on disk? I would like to disable this in my fork of chokidar

[lorenzos]

Any news on this? Also a default-off option is welcome. I see there's already a PR, but it was not accepted. Atm I can't use livereload because I'm working in a folder containing parenthesis...

[es128]

Problems with parentheses will be solved by #535 once the apparent windows issues there are resolved.

A different fix will still be needed for other sorts of glob characters like asterisks.

[lorenzos]

Still broken on Windows? I can't find details about the issue on Windows, can you explain?

[octachrome]

There is no clear way to work around this issue on Windows, where the following are all valid folder names but are indistinguishable from globs:

!folder
folder [1]
folder {1}

The latest is-glob supports escaping glob characters with backslash, but of course that doesn't work on Windows because backslash is the path separator.

Has anyone done the work to add an option to disable globbing globally? If not, would you accept a pull request to add a global option to disable globs? It would be such a minimal change and would solve a lot of people's problems.

[es128]

would you accept a pull request to add a global option to disable globs?

Maybe, but it might not be as simple as you think. I'm more eager for a PR that updates to is-glob@3 and solves the related windows issues that show up in the tests when doing so.

doesn't work on Windows because backslash is the path separator

Forward slash is also a valid path separator on Windows, so it can work. But yes, it is sometimes tricky when also using stuff like path.join()

[octachrome]

My naive approach would be to skip the isGlob check in _getWatchHelpers if the proposed global flag was set. Why would it be more complicated than that?

I'm more eager for a PR that updates to is-glob@3

How could any possible update to is-glob correctly determine whether folder [1] is a path or a glob? It is a valid folder name and a valid glob. The only way is for the user to indicate which it is. The nicest solution would be a flag to (or alternative version of) add so that the user can add both globs and paths. But a global flag solves a lot of problems for not much work, hence I suggest doing this first.

Forward slash is also a valid path separator on Windows

I don't think you want to force Windows users to use forward slashes in all their paths. That would create a lot more issues than it solves.

[es128]

Try the naive approach, let's see what happens. Honestly, I don't remember what the gotchas were when I've looked at this in the past.

Updating is-glob would allow the possibility of at least escaping the special characters - a viable workaround for this edge case. It would not require all windows paths to use forward slashes. But I agree with your perspective that any solution cannot knowingly impact other users who are not currently having problems.

[octachrome]

The disableGlobbing option is now merged into master, so if you have problems caused by unwanted globbing give it a try. (It is not yet in npm.)

[bpasero]

Very nice, thanks!

[octachrome]

@es128 Will there be a new release soon?

[es128]

Yes

[appelgran]

Since disableGlobbing isn't possible per glob or even only for the cwd option. I resolved my issue with parentheses in folder name this way { "cwd": projectdir.replace(/[()]/g, "?") }. So "folder (2)" becomes "folder ?2?" which will glob match the former.

Haven't tested but.. Maybe escape everything but * and ** (.replace(/[()!+@\[\]]/g, "?")) would be sane for my scenario using Gulp. Gulp docs never mention anything but * and ** anyway. (Glob character source.)