the buffer passed to GetFullPathName was too small

[IliaAnastassov]

Error when opening a file with a long file path

When opening a file that has a very long file path, I get the error: "the buffer passed to GetFullPathName was too small.

Steps to Reproduce the Issue

1. Create a file that has a long file path
2. Open it

Expected Behavior

Open the file with no problems

Actual Behavior

Throws an error

Debug Information

the buffer passed to GetFullPathName was too small

[CookiePLMonster]

Likely related to #4078 - even if you're not on Windows 10, that covers the same topic (and would be fixable the same way).

I'll look into it later nonetheless.

[dail8859]

@IliaAnastassov

Since you didn't provide any info about what Notepad++ version you are using, and no debug info I'm going to assume you are on an old version (older than v6.7.8) because there is nothing in the code any more that creates this message. Plus it was already reported and fixed (~3 years ago).

[CookiePLMonster]

While this specific issue may indeed be out of date, I do think it would be beneficial to gradually phase out MAX_PATH from the codebase... Especially seeing comments like this:

const rsize_t longFileNameBufferSize = MAX_PATH; // TODO stop using fixed-size buffer

In fact, removing cases like this would be trivial - all cases like this

TCHAR fullpath[MAX_PATH];
::GetFullPathName(filename, MAX_PATH, fullpath, NULL);

would need to be replaced by one call to GetFullPathName to determine required buffer size, memory allocation and then another call to GetFullPathName to actually query data. Trivially wrap-able.

Removing all MAX_PATH from those specific calls would be a very good start, I'd say.

In this specific case, MAX_PATH constraint only exists because PathFileExists doesn't accept paths longer than that... However, it can be replaced by GetFileAttributes and this limit is gone, as per note on MSDN:

In the ANSI version of this function, the name is limited to MAX_PATH characters. To extend this limit to 32,767 wide characters, call the Unicode version of the function (GetFileAttributesW), and prepend "\?" to the path. For more information, see File Names, Paths, and Namespaces.

Tip Starting in Windows 10, version 1607, for the unicode version of this function (GetFileAttributesW), you can opt-in to remove the MAX_PATH character limitation without prepending "\?". See the "Maximum Path Limitation" section of Naming Files, Paths, and Namespaces for details.

One could argue that it's not beneficial to have only some parts of n++ support paths of arbitrary length. I agree when it comes to usability, but simple, iterative changes would make this more suitable for contributions from more than one person at at time. At the moment, long paths is an enormously huge task no one wants to undertake (myself included), however making progress towards it in small iterations may make it bearable to refactor and develop.

EDIT:
So a quick test with variable length buffer, Windows 10 longPathAware manifest (prepending \\?\ disables string canonization and I'm fearing it may have nasty side effects somewhere) and generic_string storing paths ends up being successful! Manifest tool thinks longPathAware option is unrecognized but seemingly it still works fine (GetFileAttributes fails without manifest and succeds with it).

[dail8859]

I agree that there is an underlying problem with how paths are handled. Since this issue is in regards to the dialog box showing up (which no longer exists), I'll close this particular issue and any further info and discussion should be done on #4078