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

delete problems when watching a folder structure under windows #77

Closed
ECP-Black opened this issue Apr 9, 2015 · 8 comments
Closed

delete problems when watching a folder structure under windows #77

ECP-Black opened this issue Apr 9, 2015 · 8 comments

Comments

@ECP-Black
Copy link

Hello,

I have an problem with Windows 7/64 and node 0.10.37. When i watch a folder with a structure (e.g.):

/folderA/folderB/fileA.txt
/folderA/folderB/fileB.txt
/folderA/fileA.txt
/fileA.txt

It is not possible to delete folderA. But when I delete FolderB it is possible to delete folderA.
In general it is not possible to delete folders if the folder contains at least one another folder. When stopping the script i can delete all with out problems.

Thanks for help,
Dennis

@greduan
Copy link

greduan commented Apr 9, 2015

Just in case it's relevant, how are you trying to delete the folder? The command line or through the Windows file explorer?

@ECP-Black
Copy link
Author

With the Windows Explorer.
When delete the Folder with commandline:

rmdir /S folderA

It will delete the hole content in folderA but folderA keeps existing. A secound rmdir removes the folderA.

When delete with command, a very long execption occure (from watchr) an crashes.

@isaacsimmons
Copy link

I can confirm a similar problem and provide a test case and some output. Here's a sample program that works in Linux:

'use strict';

var fs = require('fs');
var os = require('os');
var path = require('path');
var watchr = require('watchr');

//Setup two nested directories for test
var watchme = path.join(os.tmpdir(), 'watchme');
var inner = path.join(watchme, 'inner');

function mkdirSafe(dir) {
  try {
    if (! fs.statSync(dir).isDirectory()) {
      fs.mkdirSync(dir);
    }
  } catch (err) {
    fs.mkdirSync(dir);
  }
}
mkdirSafe(watchme);
mkdirSafe(inner);

//Watch the outer directory
watchr.watch({
  path: watchme,
  listener: function(evt, evtPath) {
    console.log('got ' + evt + ' event for ' + evtPath);
  },
  next: function(err, watcher) {
    setTimeout(function() { watcher.close(); }, 500);
    console.log('watcher ready');
    //And delete the inner directory once the watcher is ready
    fs.rmdir(inner);
  },
  catchupDelay: 0
});

but when run on Windows (10), node errors out with the following message when the nested directory is deleted:

watcher ready
events.js:141
      throw er; // Unhandled 'error' event
      ^

Error: The task [taskgroup 0.4405489268247038 ➞  task 1 for taskgroup 0.4405489268247038] just completed, but it had already completed earlier, this is unexpected. State information is:
{ error: 'Error: watch EPERM\n    at exports._errnoException (util.js:837:11)\n    at FSEvent.FSWatcher._handle.onchange (fs.js:1216:26)',
  previousResult: [],
  currentArguments: 
   [ { [Error: watch EPERM]
       code: 'EPERM',
       errno: 'EPERM',
       syscall: 'watch',
       domainEmitter: [Object],
       domain: [Object],
       domainThrown: false } ] }
    at Task.exit (c:\watchr-test\node_modules\watchr\node_modules\taskgroup\out\lib\taskgroup.js:309:15)
    at emitOne (events.js:77:13)
    at Domain.emit (events.js:169:7)
    at FSWatcher.emit (events.js:139:14)
    at FSEvent.FSWatcher._handle.onchange (fs.js:1216:12)

Something to do with a TaskGroup Task being marked as completed more than once. Perhaps being able to set the Task's onError to 'ignore' would provide a workaround?

@mic2100
Copy link

mic2100 commented Sep 6, 2016

I have been having exactly the same issue as described by the OP. My issue is not just about the delete process, when there are child directories it will prevent the parent directory being renamed because it is open by another process!

For instance

/dir1/dir2 <-- you cannot rename or delete dir1 without an error occurring or being blocked
/dir3/file1.txt <-- you can rename or delete this directory without any issues
/dir4/ <-- you can rename or delete this directory without any issues

It looks at though as soon as a watcher is created for a directory you cannot remove or amend its parent. But if you delete the child directory first you can delete or rename it.

This only seems to happen on windows, I have tested in Linux (Debian) and OSX and both work fine.

Apart from this issue this library works exactly how I need it to. Is there any way to fix it?

@balupton
Copy link
Member

v3.0.0 was just released which is a major rewrite, can you give it a go, as I suspect it will resolve this issue 👍 Happy to re-open if not

Sorry for the late response on this, 2014 and 2015 were hard years for me!

@mic2100
Copy link

mic2100 commented Nov 3, 2016

@balupton Sorry I know you have rewritten this, I have tested this on windows and I am still getting the same errors as before. You cannot modified directories that contain sub directories. If the directory only contains a file it works fine.

This will be happening because it will be keeping an open process monitoring that sub directory and when you try to change the name or delete it you can't. I think this is more of an OS level issue than a problem with your code so I am not sure how you can even get around this issue.

This is also happening on a lot of other node filesystem libraries that I have tried.

@balupton balupton reopened this Nov 3, 2016
@balupton
Copy link
Member

balupton commented Nov 5, 2016

Hrmm. Not sure what can be done about it. Does the same issue occur with https://github.com/facebook/watchman - windows support at facebook/watchman#19 - as they use an entirely different method of watching, and I'm planning of writing a new package that where if watchman is available we use that, otherwise we use watchr

/cc @mic2100

@balupton
Copy link
Member

Seems a limitation of Node.js. Use watchman #91

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

6 participants