getting weird error - EEXIST: file already exists, open '/x/y/z.lock'

[ORESoftware]

When I calllockfile.lock(z.lock)on a file that already exists, it is giving me this error in the callback

EEXIST: file already exists, open '/x/y/z.lock'

this is weird, because I thought the purpose of this lib was to wait for the file to be deleted and then reacquire the lock.

so confused about this one, any idea what it might be?

[ORESoftware]

I think this happens simply because the original lock-holder held onto the lock for too long, if that's the case it would be nice if the "lockfile" lib threw an error that was more specific. Even if I up the wait time, still would like a better error message.

If the above is not the case, then I actually just don't know why this error occurred, but I am fairly certain the above is true.

[juanpicado]

In the line 166, the file is trying to be open with the flags wx and according the Node.js doc

'wx' - Like 'w' but fails if path exists.

Line 166

 fs.open(path, wx, function (er, fd) {
    if (!er) {
      debug('locked', path, fd)
      locks[path] = fd
      return fs.close(fd, function () {
        return cb()
      })
    }

I don't get why the wx to be honest

[isaacs]

@juanpicado That's why it's a lockfile, because if it didn't open the file with x, then two users could hold the lock at the same time. If the open succeeds, then that means that the file didn't already exist, so now you hold the lock, because you created the file successfully.

Read through the options and set a max stale time, or a wait time, or a number of retries.

[brandonros]

I'm very confused.

The only software I ever have dealing with my lockfile, is this lockfile package.

I set it to retry... 100 times... to get a lock. I need this lock to work.

What does it do? It throws an error the lock already exists.

No shit the fucking lock exists... something else is contending for it...

This package gets 1m downloads a month and I don't see a ton of open issues for it, so it is obviously me doing something wrong, but I just got fucking paged out for an on call alert at midnight because of the file already exists error, and my mind is fucking blown that a lockfile library, with built in retries, would throw this error.

Package creator/maintainer/whoever mans these issues, can you pretty please with sugar on top tell me why

lockFile.lockSync('/tmp/myLock.lock', {retries: 100});

/* do stuff */

lockFile.unlockSync('/tmp/lock.lock');

would ever throw the error? Can you confirm it threw the error after the 100 retries? Am I misunderstanding something, or is this package utter fucking shit?

--

Update: it looks like the code did retry 100 times, but with no delay. retryWait should really be allowed for sync... I'll switch to async methods though. Thanks for the library!

[isaacs]

@brandonros

You are describing a new issue, unrelated to this year-old post. Please post a new issue in the future.

To answer your question, yes, it does retry 100 times, but it cannot delay unless you are using it asynchronously. The only way to "wait" would be to spin on CPU or some other unpleasantly wasteful thing. (I see from your update that you've worked this out.)

I understand that you are frustrated, and from your point of view, this conflict has been going on for a while, and I as the author of this module accosted you in an inconvenient time with a problem. Please understand that from my point of view, our interaction began just a few moments ago with you cursing me out.

This isn't my first rodeo, and I let internet cursing roll of my back. Many long years in OSS have thickened my skin, and I've learned to see rage with more sympathy than resentment. However, most people are not me, and this approach will prove ineffective for you, and creates a less beneficial community overall. For the good of our community and your own career, please seek some more effective tools for handling your frustration in an emotionally mature way.