zkat / cacache

💩💵 but for your data. If you've got the hash, we've got the cache ™ (moved)

Home Page:https://github.com/npm/cacache

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

node_modules/.cache locking folders on windows box with too long filename error

MatthewFairbank opened this issue · comments

When deploying our packages, we clean up node_module folders on the server for cleanup, however since installing the latest uglifyjs-webpack-plugin we're hitting an error on the filename being too long in the .cache subfolder of node_modules they referred me here

node_modules.cache\UGLIFY\CONTENT\sha512\0d\ca\b49ce4203de0c2e8694cfba636580ca2438cb22e42c39605422224d428c4cbc4e16c602b72a7d61a4a14c5dd874841a02f5d793cb349435edff5b5f7d894 - The system cannot find the path specified.

we've gotten around it by using rimraf but was wondering why the sha is so long?

We've got the same problem.

I know that zkat has previously committed to not fixing this in cacache, but this is in effect a commitment to not being compatible with Windows. If that is the goal or intent, the library should be clear about this, so that people can make informed decisions about the libraries they use. If that is not the goal, then it's time to give this a rethink and find a solution.

Server 2016 and Windows 10 1607+ do support long paths, which may be a viable solution, but this capability is turned off by default.

We are also experiencing this issue via uglifyjs-webpack-plugin. The FileTracker in MSBuild does not support paths longer than MAX_PATH, which is exceeded by the hash length of cacache:

FileTracker : error FTK2009: path is too long: \\?\S:\!!REDACTED!!\node_modules\.cache\uglifyjs-webpack-plugin\content-v2\sha512\94\2b\8c33dc5fdcfb2662a60a8a13025c2809efd35d8ed31e8f8f9f67b1f2e5ec0b1ad9d673b36f385a24c90007884a05384a8387df045c4901c805a004cd3c3a

uglifyjs-webpack-plugin had an issue with this which they closed because they believe cacache should fix the issue.

Perhaps cacache could change its default hashing algorithm to something that produces shorter hashes.

Perhaps cacache could change its default hashing algorithm to something that produces shorter hashes.

the repo owner has already stated it's not going to happen. Best off just using rimraf or another library that can handle it