[Gelöst] std::filesystem_error bei path > MAX_PATH

HarteWare

Hallo zusammen,

ist es gewollt, dass std::filesystem Exceptions wirft bei z. B. std::filesystem::is_empty oder Inkrement eines std::filesystem::recursive_directory_iterator, falls der Pfad Länger als MAX_PATH ist?

#include <iostream>
#include <filesystem>
#include <stdexcept>

namespace fs = std::filesystem;

int main()
try {
	const fs::path p{"D:/KnowledgeHub/00  Computer Science/MachineLearningX/machine learning projects for mobile applications/machine learning projects for mobile applications/9781788994590_Code/Chapter06/NumberClassifier/app/src/androidTest/java/com/mlmobileapps/numberclassifier"};
	if (fs::exists(p)) {
		std::cout << "Path exists!\n";
	} else {
		std::cout << "Path (apparently) doesn't exist!\n";
	}

	fs::directory_entry d{p};
	std::cout << (fs::exists(d) ? "Directory exists!" : "Directory doesn't exist!") << '\n';
	std::cout << (fs::is_empty(d) ? "Is empty..." : "Not empty!") << '\n';

	fs::recursive_directory_iterator iter{d};
	for (auto i = fs::begin(iter); i != fs::end(iter); ++i) {
		std::cout << i->path() << '\n';
	}
} catch (const fs::filesystem_error& e) {
	std::cerr << e.what() << std::endl;
	return e.code().value();
}

$ g++ -v
Using built-in specs.
COLLECT_GCC=C:\msys64\ucrt64\bin\g++.exe
COLLECT_LTO_WRAPPER=C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-12.2.0/configure --prefix=/ucrt64 --with-local-prefix=/ucrt64/local --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --with-native-system-header-dir=/ucrt64/include --libexecdir=/ucrt64/lib --enable
-bootstrap --enable-checking=release --with-arch=nocona --with-tune=generic --enable-languages=c,lto,c++,fortran,ada,objc,obj-c++,jit --enable-shared --enable-static --enable-libatomic --enable-threads=posix --enable-graphite --enable-fully-dynamic-strin
g --enable-libstdcxx-filesystem-ts --enable-libstdcxx-time --disable-libstdcxx-pch --enable-lto --enable-libgomp --disable-multilib --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-libiconv --with-system-zl
ib --with-gmp=/ucrt64 --with-mpfr=/ucrt64 --with-mpc=/ucrt64 --with-isl=/ucrt64 --with-pkgversion='Rev10, Built by MSYS2 project' --with-bugurl=https://github.com/msys2/MINGW-packages/issues --with-gnu-as --with-gnu-ld --disable-libstdcxx-debug --with-bo
ot-ldflags=-static-libstdc++ --with-stage1-ldflags=-static-libstdc++
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.2.0 (Rev10, Built by MSYS2 project)

$ ./a.exe
Path exists!
Directory exists!
filesystem error: cannot check if file is empty: No such file or directory [D:/KnowledgeHub/00  Computer Science/MachineLearningX/machine learning projects for mobile applications/machine learning projects for mobile applications/9781788994590_Code/Chapt
er06/NumberClassifier/app/src/androidTest/java/com/mlmobileapps/numberclassifier]

Bei 258+ Zeichen (scheinbar) fängt std::filesystem::is_empty an fehlzuschlagen (vermutl. auch directory_iterator).
Bei zwei Zeichen mehr, 260+, funktioniert dann auch das std::filesystem::exists nicht mehr.

Ist das so gewollt oder ein Bug? Ernste Frage, es gibt ja das alte MAX_PATH, eigentlich kann man es in Windows inzwischen umgehen, aber vielleicht setzt der C++ Standard das absichtlich "ouf of scope" bzw. lässt es undefiniert. Man muss dann halt die Pfade erweitern mit \\?\, so wird es dann auch in Windows Explorer angezeigt.
Und ja, man könnte auch einfach GNU/Linux verwendet, I know!

Schlangenmensch

@HarteWare Hast du LongPathsEnabled in der Registry gesetzt?

https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=registry#enable-long-paths-in-windows-10-version-1607-and-later

hustbaer

@HarteWare
Also eigentliche Frage ist: Muss std::filesystem auf Windows transparent mit Pfaden länger als MAX_PATH umgehen können? Korrekt?

Wenn man diese mit "nein" beantwortet, dann ist das Werfen von Exceptions mMn. die passende Art mit langen Pfaden umzugehen (bei den Overloads ohne std::error_code& Parameter).

Was die eigentliche Frage angeht: ich weiss leider nicht was der Standard dazu sagt. MMn. wäre es schon gut wenn lange Pfage "einfach so" funktionieren würden. Nicht nur in std::filesystem sondern auch in anderen Standardfunktionen wie fopen oder sogar open.

Wenn es dir ein Anliegen ist, dann würde ich dich bitten einen Bug-Report über die Visual Studio Developer Community zu machen - und den Link dann ggf. hier zu posten. Ich geb dem dann gerne ein "+1"

hustbaer

@Schlangenmensch
Das korrekte Funktionieren der Standard-Library oder auch des eigenen Programme sollte wenn möglich halt nicht von Registry-Settings abhängig sein.

HarteWare

@Schlangenmensch War nicht 0x1, allerdings funktioniert es auch schon so in Windows Explorer. Auch nach der Änderung + Neustart keine Besserung:

These are the directory management functions that no longer have MAX_PATH restrictions if you opt-in to long path behavior:
CreateDirectoryW, CreateDirectoryExW GetCurrentDirectoryW RemoveDirectoryW SetCurrentDirectoryW.

These are the file management functions that no longer have MAX_PATH restrictions if you opt-in to long path behavior:
CopyFileW, CopyFile2, CopyFileExW, CreateFileW, CreateFile2, CreateHardLinkW, CreateSymbolicLinkW, DeleteFileW, FindFirstFileW, FindFirstFileExW, FindNextFileW, GetFileAttributesW, GetFileAttributesExW, SetFileAttributesW, GetFullPathNameW, GetLongPathNameW, MoveFileW, MoveFileExW, MoveFileWithProgressW, ReplaceFileW, SearchPathW, FindFirstFileNameW, FindNextFileNameW, FindFirstStreamW, FindNextStreamW, GetCompressedFileSizeW, GetFinalPathNameByHandleW.

@hustbaer sagte in std::filesystem_error bei path > MAX_PATH:

@HarteWare
Also eigentliche Frage ist: Muss std::filesystem auf Windows transparent mit Pfaden länger als MAX_PATH umgehen können? Korrekt?

Im Prinzip, ja, oder falls nicht, warum.

Today I learned:

GCC implementiert std::filesystem::path mit einer Liste
Die Liste wird als private Member von Grund auf implementiert, anstatt z. B. einen anderen STL Container zu verwenden
MAX_PATH ist 260 (ich dachte immer 256, das wäre halt eine schöne Zweierpotenz).
std::filesystem aus GCC libstdc++ verwendet für Windows _wstat64, hierauf konnte ich das Problem zurückverfolgen ~~(direkter Aufruf der Funktion in einem Testprogramm schlägt auch fehl ab Pfaden >MAX_PATH, d.h., >260 Zeichen)~~

~~Ich hatte auch noch versucht mit diesem \\?\-Präfix, hat auch nichts gebracht. Scheint also auf jeden Fall, dass Windows schuld ist, und nicht GCC. MSVC verhält sich gleich.~~

Wie von Microsoft beworben, funktioniert folgendes Beispiel aber schon (selbst _wstat64):

const wchar_t* filename = L"\\\\?\\D:\\KnowledgeHub\\00  Computer Science\\MachineLearningXXX\\machine learning projects for mobile applications\\machine learning projects for mobile applications\\9781788994590_Code\\Chapter06\\NumberClassifier\\app\\src\\androidTest\\java\\com\\mlmobileapps\\numberclassifier";
	WIN32_FILE_ATTRIBUTE_DATA data{};
	if (!GetFileAttributesExW(filename, GetFileExInfoStandard, &data)) {
		std::cerr << "GetFileAttributesExW failed\n";
	}
	struct _stat64 buf {};
	if (_wstat64(filename, &buf)) {
		std::cerr << "_wstat64 failed\n";
	}

Man benötigt auf jeden Fall den \\?\-Präfix bzw. \\\\?\\, siehe Doku oben verlinkt, und auch im Pfad werden nur noch \\ und keine / akzeptiert. Das funktioniert dann sowohl in MSVC als auch GCC. Vielleicht sollte std::filesystem so schlau sein und unter Windows bei Pfaden größer MAX_PATH automatisch die \\?\ und /->\ transformation vornehmen? Ich weiß es nicht. Fakt ist, Stand heute geht dann ein directory_iterator beispielsweise "kaputt", wenn der Pfad dann zu tief geht.
Evtl. kann man das auch in User-Code erkennen und handhaben, weiß nicht. Irgendwie sowas:

fs::path make_long_path(fs::path p) {
	if (p.string().size() < MAX_PATH) {
		return p;
	}
	else {
		return L"\\\\?\\" + p.make_preferred().wstring();
	}
}

hustbaer

@HarteWare sagte in std::filesystem_error bei path > MAX_PATH:

Man benötigt auf jeden Fall den \\?\-Präfix bzw. \\\\?\\, siehe Doku oben verlinkt, und auch im Pfad werden nur noch \\ und keine / akzeptiert. Das funktioniert dann sowohl in MSVC als auch GCC.

Ja, ist mir bekannt.

Vielleicht sollte std::filesystem so schlau sein und unter Windows bei Pfaden größer MAX_PATH automatisch die \\?\ und /->\ transformation vornehmen? Ich weiß es nicht.

Genau das ist die Frage. Ich würde sagen: ja, das sollte die Standard-Library intern regeln. Ziel von std::filesystem ist ja schliesslich dass man plattformübergreifend programmieren kann, und halt keine blöden #ifdef braucht.

Fakt ist, Stand heute geht dann ein directory_iterator beispielsweise "kaputt", wenn der Pfad dann zu tief geht.

Wenn man den std::filesystem::path selbst mit dem \\?\ Prefix erzeugt geht es aber, oder? Also nicht dass ich das deswegen jetzt OK/gut finden würde - will nur sicher gehen dass ich dich nicht falsch verstehe. Denn wenn es mit selbst angegebenem \\?\ Prefix auch nicht geht, dann ist das definitiv ein Bug in der Standard-Library.

Evtl. kann man das auch in User-Code erkennen und handhaben, weiß nicht.

Kann man sicher. Aber nicht ganz so einfach wie du es machst. Man sollte dabei schon sicherstellen dass z.B. der \\?\ Prefix nur angehängt wird wenn er nicht bereits vorhanden ist, auch kein \\.\ Prefix vorhanden ist etc. UNC-Pfade müssen zu \\?\UNC\hostname\... werden. Relative Pfade bzw. allgemein Pfade die . oder .. enthalten gehen auch nimmer -> muss man dann auch erst selbst in flach-gewalzte, absolute Pfade verwandeln. Und wenn man den Prefix anhängt sollte man dann auch evtl. enthaltene / durch \ ersetzen.

HarteWare

@hustbaer hmm stimmt, ich hatte wieder viel zu simpel gedacht (mit den ganzen Fallunterscheidungen). Es funktioniert aber tatsächlich relativ gut, wenn man einfach schaut, dass der "Startpfad" das korrekte \\?\ hat.

Schlangenmensch

@hustbaer Ja, da bin ich bei dir. Ich fände es gut, wenn der Standard das entsprechend regeln würde und die Compiler das entsprechend umsetzen würden.

Finnegan

@Schlangenmensch sagte in [Gelöst] std::filesystem_error bei path > MAX_PATH:

@hustbaer Ja, da bin ich bei dir. Ich fände es gut, wenn der Standard das entsprechend regeln würde und die Compiler das entsprechend umsetzen würden.

Das wäre zwar schön für den Anwender, aber eine Katastrophe zu implementieren, bei der letztendlich alles bei den Entwicklern der Standardbibliothek hängen bleibt. Das gilt besonders für GCC, der verdammt viele verschiedene Systeme unterstützt.

Ich denke der bisherige Ansatz ist da schon akzeptabel - grundsätzlich verwendet im Fall von libstdc++ die C++-Standardbibliothek hauptsächlich die Funktionen der C-Runtime für die eigene Implementierung (mit ein paar Anpassungen, so dass unter Windows z.B. _wstat64 statt stat verwendet wird). Das hat den grossen Vorteil, dass man z.B. für ein neues zu unterstützendes System lediglich eine funktionierende libc benötigt, um dort auch die C++-Standardbibliothek verwenden zu können. Diesen Vorteil würde ich nicht unterschätzen.

Wäre das Teil des Standards, wird das bei GCC m.E. nicht den erhofften Effekt haben, dass so etwas automatisch von Haus aus besser funktioniert, sondern dass es im Fall von Windows wahrscheinlich noch länger dauern wird, bis man eine neue GCC-Version nutzen kann. Immerhin ist x86_64-w64-mingw32 (mit MinGW-w64 als "C-Runtime") keine offiziell unterstützte GCC-Plattform. Lediglich das "klassische" 32-Bit-MinGW (i686-mingw32) ist als sekundäre Plattform aufgeführt. Die Entwickler von MinGW-w64 müssten dafür also erstmal die Pflege eines eigenen Branch der libstdc++ aufnehmen und diese Standardkonform halten.

Ich denke wenn überhaupt, dann diese Macken auf Ebene der C-Runtime transparent auszubügeln, wäre der bessere Ansatz. In diesem Fall wäre das die Implementierung von _wstat64 und die liegt im Aufgabenbereich des MinGW-w64-Projekts. Ich kann aber verstehen, wenn es da bedenken bezüglich Kompatibilität mit anderen Programmen geben sollte. Zumal ja auch die MS-Implementierung dieser Funktion das nicht so macht.

hustbaer

@Finnegan sagte in [Gelöst] std::filesystem_error bei path > MAX_PATH:

@Schlangenmensch sagte in [Gelöst] std::filesystem_error bei path > MAX_PATH:

@hustbaer Ja, da bin ich bei dir. Ich fände es gut, wenn der Standard das entsprechend regeln würde und die Compiler das entsprechend umsetzen würden.

Das wäre zwar schön für den Anwender, aber eine Katastrophe zu implementieren, bei der letztendlich alles bei den Entwicklern der Standardbibliothek hängen bleibt. Das gilt besonders für GCC, der verdammt viele verschiedene Systeme unterstützt.

Also da hab ich jetzt wenig Mitleid mit den Entwicklern der Standard-Library. "Der Scheiss sollte bitte auch funktionieren" ist mMn. keine übertriebene Forderung.

Ausser Windows wäre mir auch kein System bekannt wo es noch solche Probleme gibt. Von daher würde sich der Aufwand in Grenzen halten. Und speziell von MS würde ich mir mehr wünschen. Wobei ich nicht sagen kann dass ich mir mehr erwartet hätte.

Tyrdal

@Finnegan sagte in [Gelöst] std::filesystem_error bei path > MAX_PATH:

Das wäre zwar schön für den Anwender,

Und das ist alles was zählt. Wenn das nicht plattformübergreifend funktioniert, dann brauchen wir das gar nicht. Plattformabhängig kann ich auch ohne Standard programmieren.

Finnegan

@hustbaer @Tyrdal Ist die falsche Stelle meiner Meinung nach. Das Problem ist doch hier anscheinend, dass eine Funktion des Betriebssystems bzw. der C-Runtime nicht 0 zurückgibt. Ich würde vermuten, dass ich z.B. auf Linux mit backslash-separierten Pfaden ein ähnliches Resultat erhalte - womit vielleicht auch einleuchtet, weshalb es eventuell nicht sinnvoll ist, dass irgendwelche Anforderungen an Pfad-Formate Teil des Standards sein sollten, sondern vielleicht doch besser "implementation-defined".

Das spricht aber nur gegen die Aufnahme in den Standard und das automatische Umschreiben in die \\?\-Notation. Völlig in Ordnung finde ich hingegen die Forderung, GetFileAttributesExW statt _wstat64 zu verwenden, was ja scheinbar mit langen Pfaden umgehen kann. Letztere ist ohnehin keine sys/stat.h-Standardfunktion, auch wenn sie danach modelliert ist. Da kann man m.E. auch gleich die Win32-API verwenden*.

Dann gibt es noch das Problem, dass GCC Windows nur halbherzig unterstützt und bei denen als "sekundäre Plattform" eher einen "it compiles -ship it!"-Status hat. Die sollten vielleicht mal ihren Support-Status aktualisieren: Verwendet überhaupt noch jemand das klassische MinGW vs. MinGW-w64 und findet bei ersterem überhaupt noch aktive Entwicklung statt? Die Plattform sollte entweder rausfliegen oder man sollte auf MinGW-w64 wechseln und Windows etwas ernsthafter unterstützen, wozu eben auch die o.g. Verwendung von GetFileAttributesExW gehört.

Mein Verdacht ist, dass die einfach keine Entwickler haben, die aktiv mit Windows arbeiten - das ist schon extrem, was da für Verrenkungen und Patches benötigt werden, damit sich das Projekt für Windows überhaupt bauen lässt. Da hat wohl irgendwer mal vor Jahren den MinGW-Support eingebaut und seitdem wurde das nicht mehr angefasst. Ich mach mir da wenig Hoffnungen, dass sowas bei denen mal besonders weit oben auf der Prioritätsliste landet

Ich denke die besten Ansprechpartner für dieses Problem sind wahrscheinlich erstmal die Projekte wie MSYS2, die GCC für Windows bauen und ihre eigenen Patches für GCC pflegen. Meine Erfahrung mit GCC+Windows ist, dass man solche Dinge meistens selbst fixen muss und sich dann bemühen kann, dass die vielleicht irgwndwann mal Upstream landen - das wäre auch einen Versuch wert, wenn es wirklich wurmt - da muss man dann aber denke ich einen fertigen und getesteten Patch präsentieren, wenn man das wirklich irgendwann mal implementiert sehen will

* Vielleicht wollten sie auch einfach nur vermeiden, die unsägliche windows.h in einem gemeinsamen Header einzubinden - ich sag nur #define min / #define max und solches gruselige Zeug

Tyrdal

@Finnegan sagte in [Gelöst] std::filesystem_error bei path > MAX_PATH:

@hustbaer @Tyrdal Ist die falsche Stelle meiner Meinung nach. Das Problem ist doch hier anscheinend, dass eine Funktion des Betriebssystems bzw. der C-Runtime nicht 0 zurückgibt. Ich würde vermuten, dass ich z.B. auf Linux mit backslash-separierten Pfaden ein ähnliches Resultat erhalte - womit vielleicht auch einleuchtet, weshalb es eventuell nicht sinnvoll ist, dass irgendwelche Anforderungen an Pfad-Formate Teil des Standards sein sollten, sondern vielleicht doch besser "implementation-defined".

Dann ist es aber weitgehend nutzlos.

Swordfish

Nimm Python ^^

Tyrdal

@Swordfish Wie nimmt man den Python, um in C++ Plattformunabhängig mit Dateien zu arbeiten?

SeppJ

@Tyrdal sagte in [Gelöst] std::filesystem_error bei path > MAX_PATH:

@Swordfish Wie nimmt man den Python, um in C++ Plattformunabhängig mit Dateien zu arbeiten?

system("python script.py")

Swordfish

@SeppJ

Finnegan

@Tyrdal sagte in [Gelöst] std::filesystem_error bei path > MAX_PATH:

@Finnegan sagte in [Gelöst] std::filesystem_error bei path > MAX_PATH:

@hustbaer @Tyrdal Ist die falsche Stelle meiner Meinung nach. Das Problem ist doch hier anscheinend, dass eine Funktion des Betriebssystems bzw. der C-Runtime nicht 0 zurückgibt. Ich würde vermuten, dass ich z.B. auf Linux mit backslash-separierten Pfaden ein ähnliches Resultat erhalte - womit vielleicht auch einleuchtet, weshalb es eventuell nicht sinnvoll ist, dass irgendwelche Anforderungen an Pfad-Formate Teil des Standards sein sollten, sondern vielleicht doch besser "implementation-defined".

Dann ist es aber weitgehend nutzlos.

Ich denke ich muss meine Ansicht hierzu revidieren: Ich habe mir nicht richtig bewusst gemacht, dass filesystem::path eine Abstraktion von Pfaden ist, sonst könnte man schliesslich auch überall Strings verwenden. Wenn ich oben von "Pfad-Formaten" rede, dann meine ich damit natürlich die Strings, mit denen ein filesystem::path im Konstruktor initialisiert wird. Das ist ein nativer Pfad und sollte m.E. exakt übernommen und nicht irgendwie umgeschrieben werden. D.h. exists(path("<zu langer nativer pfad>")) soll schon fehlschlagen dürfen. Die Directory-Iteratoren arbeiten allerdings mit der path-Abstraktion und hier sehe ich es schon als Aufgabe der Standardbibliothek-Entwickler, das so gut wie möglich zu implementieren. D.h. die internen nativen Pfade, die beim Iterieren erzeugt werden, können schon umgeschrieben werden. Die sinnvollste Lösung ist aber wohl einfach wie erwähnt GetFileAttributesExW zu verwenden.

Der Standard sollte allerdings nicht vorschreiben, dass beliebig lange Pfade funktionieren müssen. Das ist schon in Ordnung, wenn das "implementation-defined" ist. Schliesslich soll filesystem auch Systeme unterstützen, die das schlichtweg nicht können - z.B. ein Embedded-Projekt mit einem "Flat"-Dateisystem, das nur ein Wurzelverzeichnis kennt.

Stattdessen sollte eine "gute Implementierung" den Anspruch haben, die path-Abstraktion nach bestem Wissen und Gewissen auf die nativen OS-Funktionen zu übertragen. _wstat64 und die Exception ist also m.E. zwar ein konformes Verhalten (schliesslich wird eine OS/C-Runtime-Funktion korrekt verewendet und meldet einen Fehler), aber eine "gute Implementierung" sollte sich schon mehr Mühe geben

Würde mich nicht wundern, wenn die libc++ damit klar käme. Da habe ich wenn ich mich recht entsinne relativ viel Code gesehen, der Funktionen der Win32-API direkt aufruft. Funktioniert die bei der MSYS2-Distribution, die du verwendest, @HarteWare? clang++ -stdlib=libc++ ... wäre vielleicht mal einen Versuch wert. So aus dem Bauch heraus wirkt mir die Windows-Unterstützung beim LLVM-Projekt generell etwas ernsthafter.

Edit: Hab das mal bei mir ausprobiert und bekomme mit GCC nicht einmal eine Exception. Es ist, als würden sämtliche Verzeichnisse mit einem zu langen Pfad überhaupt nicht existieren.

Ich verwende allerdings eine selbst gebaute Toolchain - die dürfte weitgehend dem MSYS2-Build entsprechen, verwendet aber bereits MinGW-w64 10.0. Die Header, die für _wstat64 und die Win32-API eingebunden werden stammen von diesem Projekt und die machen dort durchaus schonmal Anpassungen:

> gcc -dumpversion
12.2.0
> clang++ -dumpversion
16.0.0

...
std::cout << "MinGW-w64 " << __MINGW64_VERSION_MAJOR << "." <<__MINGW64_VERSION_MINOR << std::endl;
...

MinGW-w64 10.0

Mit clang++ -stdlib=libc++ bekomme ich hingegen eine Exception:

filesystem error: in recursive_directory_iterator::operator++(): attempting recursion into "D:/Temp/test-fs\very-long-path-subdirectory1\very-long-path-subdirectory2\very-long-path-subdirectory3\very-long-path-subdirectory4\very-long-path-subdirectory5\very-long-path-subdirectory6\very-long-path-subdirectory7\very-long-path-subdirectory8\very-long-path-subdirectory9": No such file or directory

Schon interessant, aber zugegeben, alles nicht zufriedenstellend... eher im Gegenteil, wenn das Verhalten jetzt auch noch scheinbar von der MingGW-w64-Version abhängt und es trotzdem nicht funktioniert wie es soll

HarteWare

Dieser Beitrag wurde gelöscht!

hustbaer

@Finnegan
Was der Standard vorschreiben sollte und was nicht ist eine Sache.
Was die Implementierung machen sollte mMn. eine andere.

Ich finde es halt doof, dass es auf Windows mit standard C++ nicht möglich ist bestimmte Verzeichnisse aufzulisten -- obwohl es mit anderen Programmen sehr wohl möglich ist auf diese Verzeichnisse/Files zuzugreifen. Fälle wo man in das Limit läuft sind auch gar nicht so selten.

Bei anderen Dingen die theoretisch auf Windows möglich sind wird es dann etwas schwieriger. Z.B. kannst du auf Windows normalerweise keine Files erzeugen die "reservierte" Namen wie "CON" oder "COM1" haben. Mit dem \\?\ Prefix geht es aber. Das Erzeugen von solchen Files über die C++ Standard Library zu erlauben fände ich z.B. nicht so gut.