playdate.file.listFiles() only showing some files

Two files seem to be ignored and instead the "./" and "../" paths are shown. I'm having this issue on Linux. The code that's running in the screen recording simply logs all the files returned.

local files = playdate.file.listFiles("files")
for i = 1, #files do
	print(files[i])
end
playdate.update = function() end

Good catch! We'll get this fixed in a future update.

1 Like

Is this issue fixed in 1.10.0? It's not mentioned in the changelog.
I'm on Linux, and listFiles() is returning one less file than expected.

If the directory has one real file "foo", listFiles returns "../" (and not "./").
If it has "foo" and "bar", listFiles() returns "../" and "foo".

1 Like

I could't reproduce this when I tested it with the above sample code. What distro are you using? In the original post it looks like Elementary; I tested it on Fedora 35. I'll look at it again today on EOS.

I'm on Ubuntu 21.10.
By any chance, is the code relying on the output of readdir being sorted? It is not.
For example, readdir in the directory that made me aware of this bug gives me the files in this order:

foo
.
rdk.json
baz
bar
..
1 Like

Just replicated this on Ubuntu 22.04
repro.zip (580 Bytes)

1 Like

The issue is, in fact, on macOS readdir() returns . and .. as the first results while on Ubuntu (and not Fedora??) it is unordered. I am fixing this now. Thanks for the follow-up!

3 Likes

Yeah, order is not guaranteed by the POSIX standard, and the Linux manpage warns about it:

The order in which filenames are read by successive calls to readdir() depends on the filesystem implementation; it is unlikely that the names will be sorted in any fashion.

Is the fix slated for a future SDK release, or was it supposed to be fixed already? 1.11.1 is still exhibiting the issue.

1 Like

The fix isn't in a release yet; hopefully the next release.

2 Likes