Getting issue in npm install WARN tarball tarball data for @angular/compiler@7.1.0


(Rahul Winner) #1

I’ve an Angular app. Yesterday all of sudden we have started getting tarball corrupted error on ‘npm install’. We are using npm and nodes version 6.4.1 and 8.12.0 respectively. Error is as follows.

We tried many troubleshooting steps likewise 1) npm cache clean --force 2) delete .npmrc etc, but nothing worked so far.

Can anyone please help us.

 [echo] NPM INSTALL
 [exec] npm WARN tarball tarball data for @angular/compiler@7.1.0 (sha512-1Hjx6e+lVXZyXFFe4OW34ZpiaGEYyB1MQ7k2C+cMm0ABMQS3LsWT4DYhY7bk0mmMuuXQj66C62MX76ladDtdIg==) seems to be corrupted. Trying one more time.
 [exec] npm WARN tarball tarball data for typescript@3.1.6 (sha512-tDMYfVtvpb96msS1lDX9MEdHrW4yOuZ4Kdc4Him9oU796XldPYF/t2+uKoX0BBa0hXXwDlqYQbXY5Rzjzc5hBA==) seems to be corrupted. Trying one more time.
 [exec] npm ERR! path /data/XXxxxx/xxxx/myproject/node_modules/.staging/typescript-a7396b0c/lib/.nfs000000008ba795620000c72c
 [exec] npm ERR! code EBUSY
 [exec] npm ERR! errno -16
 [exec] npm ERR! syscall unlink
 [exec] npm ERR! EBUSY: resource busy or locked, unlink

error while installing angular/cli
(Rahul Winner) #2

Could anyone please help me out? It is causing serious issue to our project.

Thanks for any guidance.


(Lars Willighagen) #3

For the tarball warnings, have you tried deleting package-lock.json? The error seems to be related to this, are you using NFS?


(Rahul Winner) #4

Yes. We are using NFS on linux machines.
However, we are getting this issue over windows machines as well.

We tried deleting package-lock.json but we still got the same problem. We noticed that it does not fail for angular packages only, but fails for some other packages e.g. typescript too.

Please suggest.


(Lars Willighagen) #5

Well, quoting the other post:

See the linked paper, section III(g):

This file is named in the form .nfsXXXX, where the XXXX value is determined by the inode of the deleted file - basically a random value. If a process (such as rm) attempts to delete this new file from the client, it is replaced by a new .nfsXXXX file, until the process with the file open closes it.

These files are difficult to get rid of, as the process with the file open needs to be killed, and it is not easy to determine what that process is. These files may have unpleasant side effects such as preventing directories from being removed.

@zkat What other process would still have the file open, do you think? Otherwise, perhaps have either rimraf or graceful-fs skip .nfs##### files when deleting directories? (not that that’s really possible either :grimacing:)


(Rahul Winner) #6

@larsgw thank you for your help.

Could this problem be due to network delay or latency? If yes, is there any way we could confirm it? In other words, how could we ensure that it is only because of network issue. Some of us in my team are suspecting that it is because of network latency. I’m little naive to network nuances. This will provide us some background for reaching out to our IT team.

Regards, Rahul