You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
[REQ]: Create ISO full path length limited to 255 characters. Can you make it up to 32767?
- Thread starter XYZ
- Start date
This question is unclear. Are you expecting NTLite to handle longer pathnames while preparing an image, or do you want Windows support for longer pathnames in general? The reg change for enabling long pathnames at the Windows API level is known, but that doesn't imply all programs (especially legacy Win32 apps) will permit them.
Maximum Path Length Limitation
Maximum Path Length Limitation
Legacy apps can support long paths up to 32767 chars if they prefx path with "\\? \" and use Unicode versions of Win32 API calls, which is easy to do. Each component in the path can only be 255 chars, but total length can be 32767 chars.
The specific issue I had at the time was on the final page where you enable "Create ISO" and then choose a path and ISO filename to use, where my total path length exceeded 255/256 chars. NTLite trimmed it to 255/256 chars.
It's possible this also actually unearthed a bug with the buffer not being large enough by maybe 1 character (eg. not account for terminating NUL character), as during processing, NTLite crashed with a Heap error - no crash dump was created.
After re-processing the image with a shorted ISO path name, it went through fine.
The specific issue I had at the time was on the final page where you enable "Create ISO" and then choose a path and ISO filename to use, where my total path length exceeded 255/256 chars. NTLite trimmed it to 255/256 chars.
It's possible this also actually unearthed a bug with the buffer not being large enough by maybe 1 character (eg. not account for terminating NUL character), as during processing, NTLite crashed with a Heap error - no crash dump was created.
After re-processing the image with a shorted ISO path name, it went through fine.
This would be more of a bug, regardless of the buffer length NTLite shouldn't crash.
The possible concern is W7 & 8.1 don't allow longer paths, so you would need to handle this case, especially if you allow presets to be imported from W10/11. Yes, you can run W10/11 presets as long as they don't add updates, enable/disable features, or do advanced DISM cleanup.
The possible concern is W7 & 8.1 don't allow longer paths, so you would need to handle this case, especially if you allow presets to be imported from W10/11. Yes, you can run W10/11 presets as long as they don't add updates, enable/disable features, or do advanced DISM cleanup.
The crash is indeed a bug, if caused by buffer overflow, but my original request for NTLite to handle up to 32767 chars still stands.
The registry hack will only work on Windows 10, but the method I suggested (ie. prefixing path with "\\? \" and using Unicode versions of Win32 API calls) works back to Win XP at least, and maybe back to Win 2000, and is a simple change.
The registry hack will only work on Windows 10, but the method I suggested (ie. prefixing path with "\\? \" and using Unicode versions of Win32 API calls) works back to Win XP at least, and maybe back to Win 2000, and is a simple change.