PDA

View Full Version : Issues with long path names



Tom H.
06-01-2017, 09:14 AM
Hi!

We recently had a request to accommodate very long path names in our programs. In testing, we have run into a couple of issues with SB10 when trying to install into those folders with long names.

Issue #1 demonstrates an error after a long path name has been selected.

453345344535

Issue #2 is with a slightly shorter path that seems to get past the first error, but fails as well.

4536

Thanks,
Tom

linder
06-02-2017, 02:44 AM
Hi Tom,

Hmmm, interesting. Would it be possible for you to send me your test project (.sbp)?

Thanks,
Friedrich

linder
06-02-2017, 02:55 AM
Tom,

I can reproduce this now, definitely a buffer-overrun bug in the SB runtime! Thank you for bringing this to my attention. Item in review.

Friedrich

linder
06-02-2017, 04:10 AM
Update 1: most internal and external I/O components in SetupBuilder make use of the standard MAX_PATH in the Windows APIs. The maximum length for a path is MAX_PATH, which is defined as 260 characters. We have to check if it's possible to increase MAX_PATH without creating negative side effects :-(

Update 2: starting in Windows 10, version 1607, MAX_PATH limitations have been removed from common Win32 file and directory functions. We have to find out how to handle this scenario for Windows environments prior Windows 10, version 1607 and how to opt-in to the new behavior. Interesting problem. In the Windows APIs to create, say, a directory, the specified path cannot be so long that you cannot append an 8.3 file name (that is, the directory name cannot exceed MAX_PATH minus 12).

Update 3: even WinZip only supports the "Simple Long Path" method. 260 characters is the maximum (the unzip process fails here because the internal folder structure and the output folder is >260 bytes). But of course, we have to fix the buffer-overrun bug in SB.

To sum it up: 260 bytes is the expected limit for all systems prior Windows 10, version 1607.

Friedrich

Tom H.
06-02-2017, 03:37 PM
Friedrich,

Thanks for looking into it! I understand the overall 260 limit, the kicker was having a segment of the path be so long even if the total was valid. My testers report that somewhere between 170 and 180 is the fall-over/error.

Thanks for the stellar support, as usual.

Tom H.

linder
06-06-2017, 05:44 AM
Hi Tom,

Thank you !!! :) It will definitely be fixed in the soon coming maintenance build.

Friedrich

Tom H.
06-07-2017, 12:10 PM
Any indication when 'soon' might be?

I know, I know... later than 'now', but before 'later'.:p

Thanks,
Tom

linder
06-08-2017, 05:27 AM
....better than "one day after never" <vbg> ;)

I'll send you a test SB version (with the buffer overrun fix and the RTF hyperlink enhancement) within the next 48 hours.

Friedrich

linder
06-09-2017, 03:28 AM
Hi Tom,

Even a target directory with 225 bytes plus a "Test" subfolder (5 bytes) plus SB10.EXE filename (8 bytes) work fine (= 238 bytes). I can't reproduce the 170-180 bytes limit on any machine here :(

Update: the limit is (with no buffer-overrun): 251 bytes.

Friedrich

linder
06-09-2017, 03:50 AM
Update 2: 252 bytes gives this (but still no buffer-overrun). The target path can't be created, because it's too long. Adding more bytes and beginning with 268 bytes, we see a buffer-overrun (this has to be fixed).

Update 3: I have fixed the buffer-overrun bug in our recursive "Create Folder" function.

Friedrich

Tom H.
07-07-2017, 09:17 AM
Hi Friedrich,

Any news on this? We're getting ready to do a release, so I'm being asked whether we'll have an updated SB to build the installs.

Thanks!
Tom H.

linder
07-10-2017, 03:45 PM
Hi Tom,

I can send you a private build that fixes this buffer-overrun.

Friedrich

Tom H.
07-10-2017, 06:00 PM
If it doesn't mess you up, that would be great.

Please let me know if there is anything else to watch for since this wouldn't be an official release...

Thanks,
Tom H.

linder
07-11-2017, 02:55 AM
Hi Tom,

we're in the midst of finalizing a brand new SB update with quite a few runtime and compiler changes. So I think it would be a good idea to just "backport" the buffer-overrun fix (only one source code modification) to the original build 5452 to be on the safe side. Would this be okay for you?

Friedrich

Tom H.
07-17-2017, 05:51 PM
Sorry for the late reply. Yes, anything is good.

Thank you!
Tom H.

linder
08-01-2017, 04:50 AM
Tom,

Sorry for the delay. Just returned from vacation. Office was closed from July 15, 2017 - July 31, 2017. Do you still need the "special" build with this fix?

Friedrich

Tom H.
08-10-2017, 11:43 AM
Hi,

We had to release with the existing code.

If the next official SB build is coming reasonably soon, we can wait.

Thanks,
Tom H.

P.S. I hope you had a great vacation!

Tom H.
11-29-2017, 03:36 PM
Hi!

The just released 5710 update didn't seem to fix this - I just want to be sure this is still outstanding?

Thanks!
Tom H.

linder
11-30-2017, 04:05 AM
Hi Tom,

hmmm, the fix is part of this current build:

FIX : Installer: Work around a possible LFN buffer overrun issue when installing files where the file/folder name is > 256 bytes.

So you are still getting the same buffer overrun in your install? I can't reproduce it here :-( Would it be possible to send me a small test project?

Sorry for that :-(

Friedrich