Hi,

Under Linux the maximum file length is 255 character. Gnome's Nautilus allows that length. Any larger and Nautilus or a terminal command like 'cp' complains.

FindFile / FindNext however seems to have a 253 character limit! Why the difference when the OS can support up to 255 characters?

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

I forgot to attach my applications output. In the first run, the file is 253 characters long. FindFile/FindNext found 15 entries, which is correct. I then changed the file to be 254 characters long and now FindFile/FindNext exits as soon as it gets to that file.

./filegrid
found: ..
found: .svn
found: ooooooooooooooooooooooooooeeeeeeeeeeeeeeeeeeeeeeeuuuuuuuuuuuuuuuaaaaaaaaaaaaaaaaaaaaaaaoooooooooooooooooooooooooeeeeeeeeeeeeeeeeeeeuuuuuuuuuuuuuuuuuuuuuuueeeeeeeeeeeepppppppppppppppppppppphhhhhhhhhhhhhhhhhhhhhhhhhtttttttttttttttsssssssssssssaaaaaaa.txt found: units
found: test_link
found: filegrid_diff.patch
found: .
found: filegrid.lpr
found: filegrid.lps
found: filegrid.compiled
found: extrafpc.cfg
found: filegrid.lpi
found: filegrid
found: .I_should_be_hidden
found: t2

[... increment file by one extra character...]

./filegrid
found: ..
found: .svn
found: units
found: test_link
found: filegrid_diff.patch
found: .
found: filegrid.lpr
found: filegrid.lps
found: filegrid.compiled
found: extrafpc.cfg

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

I believe that this is caused by lack of careful testing. Some time ago I've found a similar-looking limitation in Windows commandline handling and posted a patch (Mantis #10175).
Btw, strange to hear about 255 character limit on Linux. Its headers define MAX_PATH value as 4097.

Best regards,
Sergei

Nono, TSearchRec only contains the filename; MAX_PATH is the length of a full path, the maximum length of a filename is not 4079.

Michael.

Sergei Gorelkin wrote

Btw, strange to hear about 255 character limit on Linux. Its headers define MAX_PATH value as 4097.

I thought the same at first, but then realized there is a difference between filename length and path length. I believe Michael's explanation hits the nail on the head.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Now I have understood it, too :)

I could reproduce the issue on my Linux, with the tiny difference: maximum working filename length for me is 252, not 253 as in your case (???).
It turns out that for longer filenames fpreaddir() failes with errno=22 (invalid argument).

Best regards,
Sergei.

Sergei Gorelkin wrote

It turns out that for longer filenames fpreaddir() failes with errno=22 (invalid argument).

Here is what I could find out:

In fpc, sizeof(dirent) is equal to 275, while gcc reports sizeof(dirent64)=276. Moreover, Linux kernel expects buffer for getdents64 syscall rounded up to 8 bytes (see fs/readdir.c in kernel source tree, macros ROUND_UP64 and NAME_OFFSET). Using these macros, we can calculate that for 255 char filename, a 280-byte buffer is expected (and value of 280 *is* returned in d_reclen field when filename length is 255). But that is still not working, for the reason I could not figure out. Only adding eight more bytes, i.e. using 288 bytes buffer, makes that syscall finally succeed with a 255 char filename.

A quick fix seems to just extend Dirent record with extra bytes, but perhaps there exists a more clean and consistent solution.

Best regards,
Sergei.