<table><tr><td style="">i.Dark_Templar added a comment.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D8413" rel="noreferrer">View Revision</a></tr></table><br /><div><div><p>I'm not sure what part exactly is broken. It's just an incompatibility between linux (posix maybe?) file length limits and windows (ntfs) limits. I'm using default gentoo libc (sys-libs/glibc-, "GNU lib C library"). I've ran filelight under valgrind and didn't notice any warnings that glibc writes anything to wrong memory address. I've looked it up, and it looks like glibc allocates buffer large enough to hold more than NAME_MAX path (on my system it allocates 32768 bytes for whole DIRP, struct dirent and additional internal stuff). And it has a special structure field d_reclen to indicate the actual length of returned record. In my case d_reclen holds value 288 (for a filename 264 bytes long). It's not fully standard compatible, but I guess it helps to work around such system design incompatibilities and usually goes unnoticed by users.</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R352 Filelight</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D8413" rel="noreferrer">https://phabricator.kde.org/D8413</a></div></div><br /><div><strong>To: </strong>i.Dark_Templar, sitter, kfunk, sandsmark<br /><strong>Cc: </strong>sandsmark, kde-utils-devel<br /></div>