fs.unlink on directory causes UNKNOWN error

[TrevorBurnham]

If 'dir' is a directory, then fs.unlinkSync('dir') throws, and fs.unlink passes,

Error: UNKNOWN, unknown error 'dir'

(tested on Node 0.6.1 under OS X). Is it possible to generate a more precise error? For comparison, rm dir provides the output

rm: dir: is a directory

[tshinnic]

Still true with 0.6.2 on Windows

  > fs.unlinkSync('foo');
  Error: UNKNOWN, unknown error 'foo'
      at Object.unlinkSync (fs.js:443:18)

With 0.6.2 on Linux, something more likely:

  > fs.unlinkSync('foo')
  Error: EISDIR, illegal operation on a directory 'foo'
      at Object.unlinkSync (fs.js:443:18)

[TrevorBurnham]

Interesting. So the question is: Can we bring the EISDIR error to Windows and OS X?

On Nov 20, 2011, at 5:14 AM, [email protected] wrote:

Still true with 0.6.2 on Windows

fs.unlinkSync('foo');
Error: UNKNOWN, unknown error 'foo'
at Object.unlinkSync (fs.js:443:18)

With 0.6.2 on Linux, something more likely:

fs.unlinkSync('foo')
Error: EISDIR, illegal operation on a directory 'foo'
at Object.unlinkSync (fs.js:443:18)

---

Reply to this email directly or view it on GitHub:
#2096 (comment)

[peppage]

I tried this on windows and I get a different error now.

$ node -v
v0.10.26

> fs.unlinkSync('foo');
Error: EPERM, operation not permitted 'c:\workspace\node-test\foo'
    at Object.fs.unlinkSync (fs.js:760:18)
    at repl:1:4
    at REPLServer.self.eval (repl.js:110:21)
    at repl.js:249:20
    at REPLServer.self.eval (repl.js:122:7)
    at Interface.<anonymous> (repl.js:239:12)
    at Interface.EventEmitter.emit (events.js:95:17)
    at Interface._onLine (readline.js:202:10)
    at Interface._line (readline.js:531:8)
    at Interface._ttyWrite (readline.js:760:14)

On linux I still get the EISDIR error.

[indutny]

@peppage EPERM is what OSX's unlink() syscall naturally returns for directories:

    [EPERM]            The named file is a directory and the effective user ID of the process is not the super-user.

     [EPERM]            The directory containing the file is marked sticky, and neither the containing directory nor the file to be removed are owned by the effective user ID.

Also, I think we should be returning the same thing for windows in the latest node (v0.11): https://github.com/joyent/libuv/blob/master/src/win/fs.c#L676 , could you please check it out?

[indutny]

Unfortunately, non-BSD systems seems to return EISDIR in such case indeed.

[indutny]

I don't think that we are going to unify it, sorry.