QFileSystemModel fails to display or access paths exceeding PATH_MAX.

Summarisation

When navigating directory trees containing paths exceeding PATH_MAX (typically 4096 bytes), QFileSystemModel and related Qt I/O classes silently fail to enumerate or index those paths. This includes paths that exceed the limit only when fully resolved (i.e., deeply nested chains of NAME_MAX entries).

Reproduction

1. Nest directories until the path of the most nested exceeds 4096 characters.
2. Launch a Qt application using QFileSystemModel, pointing to that base path.
3. Observe that no contents beyond the PATH_MAX boundary are shown.

I have attached 3 files which demonstrate this

1. path_generator_openat
2. fdviewer
3. qfilesystemmodel_test

...inside path_max_with_bypass_viewer.tar.lzma.

├── CMakeLists.txt
├── fdviewer
├── fdviewer.pro
├── Makefile
├── path_generator_openat
├── path_generator_openat.cpp
├── path_generator_openat.o
├── path_generator_openat.pro
├── pathmax_fdviewer.cpp
├── pathmax_fdviewer.o
├── pathmax_qfilesystemmodel.cpp
├── pathmax_qfilesystemmodel.o
├── pro.sh
├── qfilesystemmodel_test
└── qfilesystemmodel_test.pro

1 directory, 15 files

qfilesystemmodel_test demonstrates that QFileSystemModel cannot bypass this, whereas fdviewer demonstrates how to.

Expected Behaviour

QFileSystemModel should be able to list and traverse paths regardless of length, using openat()/fdopendir() with file descriptors if necessary.

Actual Behaviour

Files and folders beyond the limit are silently omitted. No error is raised, but they are inaccessible in the model.

Proposed Solution

Refactor QFileSystemModel (or offer an alternative) that utilises file descriptor-based traversal (openat(), fdopendir(), and fstatat()) to remove reliance on null-terminated path strings bounded by PATH_MAX.

Tangential

1. I've no reason to believe that this is deliberate, because https://bugreports.qt.io/browse/QTBUG-6960?focusedId=289538&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-289538 explicitly rejects a proposal to hardcode PATH_MAX (albeit for a procedural reason).
2. Originally discussed at https://discuss.kde.org/t/what-component-do-all-kde-applications-call-that-prevents-them-opening-directories-and-files-whose-absolute-paths-are-path-max-s-value/36442/3?u=rokejulianlockhart.