Retry rename on EBUSY #2237

Closed
piscisaureus opened this Issue Mar 7, 2012 · 7 comments

Comments

Projects
None yet
6 participants
@piscisaureus

https://github.com/isaacs/npm/blob/af7a466e53c096e54534009e89304e16a7ef1828/lib/utils/tar.js#L192

Next versions of node (including 0.6.13) can also report EBUSY under similar conditions.

@timoxley

This comment has been minimized.

Show comment Hide comment
@timoxley

timoxley Jan 7, 2014

Member

@piscisaureus is this still an issue?

Member

timoxley commented Jan 7, 2014

@piscisaureus is this still an issue?

@piscisaureus

This comment has been minimized.

Show comment Hide comment
@piscisaureus

piscisaureus Jan 7, 2014

versions of node (including 0.6.13) can also report EBUSY under similar conditions.

^ that's still true. Does NPM handle that situation in a helpful way now? I don't know.

versions of node (including 0.6.13) can also report EBUSY under similar conditions.

^ that's still true. Does NPM handle that situation in a helpful way now? I don't know.

@timoxley

This comment has been minimized.

Show comment Hide comment
@timoxley

timoxley Jan 7, 2014

Member

@piscisaureus looks like this logic is somewhat handled by https://github.com/isaacs/lockfile now, and it seems less discriminate about retries: https://github.com/isaacs/lockfile/blob/master/lockfile.js#L141

When npm is unpacking the tar, it doesn't seem to attempt retries at all now, so I'm guessing it relies on lockfile to make sure the coast is clear for writing, i.e. perhaps this issue can be closed?

Member

timoxley commented Jan 7, 2014

@piscisaureus looks like this logic is somewhat handled by https://github.com/isaacs/lockfile now, and it seems less discriminate about retries: https://github.com/isaacs/lockfile/blob/master/lockfile.js#L141

When npm is unpacking the tar, it doesn't seem to attempt retries at all now, so I'm guessing it relies on lockfile to make sure the coast is clear for writing, i.e. perhaps this issue can be closed?

@tj

This comment has been minimized.

Show comment Hide comment
@tj

tj Jan 22, 2014

Contributor

I'm getting this a lot lately as well, pretty much every install

Contributor

tj commented Jan 22, 2014

I'm getting this a lot lately as well, pretty much every install

@tj

This comment has been minimized.

Show comment Hide comment
@tj

tj Jan 22, 2014

Contributor

I also get weird shit like:

  error - Error: ENOTEMPTY, rmdir '/home/vagrant/dev/segmentio/api/node_modules/s-api/lib/ingestion'

completely at random, I really don't know what npm is even trying to do

Contributor

tj commented Jan 22, 2014

I also get weird shit like:

  error - Error: ENOTEMPTY, rmdir '/home/vagrant/dev/segmentio/api/node_modules/s-api/lib/ingestion'

completely at random, I really don't know what npm is even trying to do

@iarna iarna added the bug label Oct 17, 2014

@smikes

This comment has been minimized.

Show comment Hide comment
@smikes

smikes Dec 9, 2014

Contributor

These look like the signatures of older race conditions, fixed in newer (>2.1.0) versions of npm. Can this issue be closed now?

Contributor

smikes commented Dec 9, 2014

These look like the signatures of older race conditions, fixed in newer (>2.1.0) versions of npm. Can this issue be closed now?

@othiym23

This comment has been minimized.

Show comment Hide comment
@othiym23

othiym23 Dec 18, 2014

Contributor

The original issue is no longer relevant, because that code was taken out of npm long ago; the rest are due to race conditions, as @smikes said, and as such have been (as far as I know) remedied by subsequent changes in npm@2. Closing as resolved.

Contributor

othiym23 commented Dec 18, 2014

The original issue is no longer relevant, because that code was taken out of npm long ago; the rest are due to race conditions, as @smikes said, and as such have been (as far as I know) remedied by subsequent changes in npm@2. Closing as resolved.

@othiym23 othiym23 closed this Dec 18, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment