This is actually the old windows api limitation that paths over 256 chars (if i remember correctly) are not supported.
But thats ancient stuff and windows got an api that supports 32k long paths for many years and apps like 7zip and so on use that one.
Seems that the nsis installer version you are using does not, therefore, apps with longs paths (like most nodejs apps that have node_modules within node_modules and so on....) fail.
You are here
installer unable to extract long file paths
September 12, 2015 - 4:51am
#1
installer unable to extract long file paths
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on Facebook
Follow us on LinkedIn
Follow us on Twitter
Follow us on Mastodon
Follow us on BlueSky
Any issues like that would be due to NSIS itself. NSIS supports path lengths of 1,024 characters total with Unicode version 2.x, which we are based on. As this is an extreme edge case and doesn't affect regular apps, this will likely be a WONTFIX. If your app has paths longer than 1000 characters, you may want to rework your directory structure.
Sometimes, the impossible can become possible, if you're awesome!
It is not my dir structure and it is not my app.
Like I wrote, for node.js apps, with node_modules in node_modules (and so on...) its very easy to hit the limit like I did.
It wasn't my app to begin with so nothing I can do to resolve the issue and windows does support 32k.
NSIS 2 dev ended in 2009 where NSIS 3 is alive and kicking and well maintained.
NSIS 3 is still only a beta and should not be used for production/stable applications.
NSIS 2 was abandoned in 2009 and was ANSI-only (aka Windows 9x compatible and bad at multilingual).
NSIS Unicode is a branch of NSIS 2 and was created and maintained by a third party with the last release in 2012 of 2.46.5. It is stable and linked to by the official NSIS site. Patches are still being made and 3 additional source-only releases have been made since 2012. It's what projects should be using until NSIS 3 is deemed stable.
According to the NSIS Unicode website, paths of 8,096 characters are supported. I've found that most software, however, won't support paths that long.
Sometimes, the impossible can become possible, if you're awesome!
Move the folder you are trying to package.
The Installer's path limitation includes the depth at which you are working, not just the depth of files within the folder you are trying to package.
When I was working on Koala (also Node-based) I ran into the same issue, but moving the folder out of my Dropbox and into the root of the drive allowed me to package it up without a problem.
I'm surprised it made a difference as DropBox would only add around a hundred or so characters assuming old style Documents and Settings folder layouts and a few sub-folders deep within DropBox itself.
Sometimes, the impossible can become possible, if you're awesome!
It was a bit under a hundred, but yeah, it was enough for that particular app to get it under the character limit.
It is good for installation, but not related to packaging unless i'm missing something.
And I'm not sure I can ask people to move their paf to the root C: folder or workarounds like that which I did for me but others won't.
I did not have a problem installing from the paf.exe after it was packaged, only in the initial packaging.
I think I installed it to a similar depth, but I may be wrong since it was a while ago.
I'm closing this bug as a WontFix for now. This is a very extreme edge case involving node.js web-based apps, which isn't really what we do. Trying to rework NSIS 2 Unicode to support 32K paths or upgrading to the NSIS 3 beta just to support node.js's incredibly wonky path depths isn't really a good use of resources at present and could easily introduce bugs.
Additionally, I just checked and NSIS 3 appears to have the same limits as base NSIS 2 at present... meaning far less than 8k (NSIS 2 Unicode includes the 8k patches). There is a separate build of the current NSIS 3 beta with strlen 8k support but it is not the default. Hopefully they'll include it in final.
Sometimes, the impossible can become possible, if you're awesome!
Instead of closing you could provide creative ways for people who package such apps, for example, since 7zip does support 32k paths, the installer could package a zip file instead of the files flat, and than run 7zip to unzip them in the target directory.
So providing instructions on how to implement that, could resolve the issue for users of long path apps.
Also, its not extreme edge as the industry is moving to that type of technology. IoT anyone?
So i would like to see either instructions how to implement my suggestion, or have another better, more "paf" way of doing it.
Let's get specific... what is the app that you're trying to package, how are you trying to package it, and why should it be a portable app as opposed to just live on a server on the internet? If you have a legitimate app that you'd like to package in PortableApps.com Format for distribution, please post a new thread in the Development forum explaining exactly what you're trying to do with a zip or 7z version of your app.
Sometimes, the impossible can become possible, if you're awesome!
See thread: https://portableapps.com/node/43424#comment-224198
someone requested atom and I did package it a long time ago for personal use so figured maybe I'll help him out.
When I upgraded to newest atom, I saw the paths are a lot longer and install failed (I had to put in root to solve issue, but thats not a solution).
Opening internet? thats for websites, not apps that have access to the local file system like editors/IDE as atom.io.
Is it one of the bundled extensions? Do you happen to know the longest path that gave you issues offhand?
Sometimes, the impossible can become possible, if you're awesome!
I actually packaged atom.io flat, without installing anything on top.
so maybe it is one of the internal extensions, i'm not sure, but if it is, its part of the core app that they package as baseline.
I didn't check which node module gave me trouble, just that running the installer on the C: root drive solve it (and than cut/paste to the paf apps dir).
Could you try compiling at the location you were doing it before and paste in the end of your error log here? It should create one. Or the compiler should give you a message on the screen. I was just able to compile the base atom.io within my C:\Users\Username\Desktop\AtomPortable directory. By adding directories of different lengths, I was able to get some errors, though, and I'd like to see what you see. If you need to blank out a particular directory (like your username) just use X for each character, but preserve the exact length, please.
Sometimes, the impossible can become possible, if you're awesome!
Due to the long path, the paf uninstall doesn't work.
again, same issue due to working with old windows api.
Those 2 files were left in the drive so i guess those 2 files are also the ones that cause the issue when installing,
its is the npm module packaged inside atom and npm is the most common module there is as it is the package manager for the other modules.
C:\Users\XXXXXX\Desktop\PortableApps\PortableApps\AtomPortable\App\Atom\resources\app\apm\node_modules\npm\node_modules\request\node_modules\har-validator\node_modules\is-my-json-valid\node_modules\generate-object-property\node_modules\is-property\is-property.js
C:\Users\XXXXXX\Desktop\PortableApps\PortableApps\AtomPortable\App\Atom\resources\app\apm\node_modules\npm\node_modules\request\node_modules\har-validator\node_modules\is-my-json-valid\node_modules\generate-object-property\node_modules\is-property\package.json
Do you need more info?