[Bug] io.readdir("@resource/subdirectory") no longer enumerates unreferenced resource files on Enhanced Cfx Server

[xalva98]

Summary

io.readdir("@resource/subdirectory") no longer enumerates files inside a resource correctly on the Enhanced Cfx Server.

This is a regression from legacy FXServer behavior.

A resource can contain a directory which is intentionally not declared in files {} or another manifest entry. On legacy FXServer, that directory is still part of the resource's server-side VFS mount and can be enumerated using io.readdir("@resource/...").

On Enhanced, the same code returns no files, breaking resources which use the server-side resource VFS to discover files dynamically.

Issue type

Server

Repro rate

Always

Server build version

b96-ea

OS

No response

CPU

No response

GPU

No response

RAM

No response

Storage type

None

Connection type

None

ISP and bandwidth

No response

DxDiag

No response

Network graph

No response

Platform

None

OS version / distribution

No response

CPU

No response

RAM

No response

Using txAdmin?

None

Hosting provider

None

Machine type

None

/perf endpoint output

No response

DDoS protection

No response

ulimit -n value (Linux only)

No response

Docker Compose file (Docker only)

No response

Steps to Reproduce

Create the following minimal resource:

readdir_repro/
├── fxmanifest.lua
├── server.lua
└── clientloader/
    └── test.lua

fxmanifest.lua:

fx_version 'cerulean'
game 'gta5'

server_script 'server.lua'

clientloader/test.lua:

print('test')

The clientloader directory is intentionally not declared in the resource manifest.

server.lua:

local resource = GetCurrentResourceName()
local path = ("@%s/clientloader"):format(resource)

print("resource:", resource)
print("resource path:", GetResourcePath(resource))
print("readdir path:", path)

local handle, err, code = io.readdir(path)

print("handle:", tostring(handle))
print("error:", tostring(err))
print("error code:", tostring(code))

local count = 0

if handle then
    for name in handle:lines() do
        count = count + 1
        print(("entry %d: %s"):format(count, name))
    end

    handle:close()
end

print("entry count:", count)

Start the resource:

ensure readdir_repro

Run the exact same resource once on legacy FXServer and once on Enhanced Cfx Server.

Expected Behavior

The server-side resource VFS should expose the contents of the physical resource directory.

io.readdir("@readdir_repro/clientloader") should enumerate:

test.lua

Expected output:

resource: readdir_repro
readdir path: @readdir_repro/clientloader
entry 1: test.lua
entry count: 1

This is how the same code behaves on legacy FXServer.

Files should not need to be declared in files {} merely for server-side filesystem enumeration of the resource's own directory.

Actual Behavior

On Enhanced Cfx Server, the directory does not enumerate its contents.

The original affected resource consequently reports:

[saltychat] No clientloader .lua files found!

and later:

[saltychat] Player 2 requested code but no batches exist

The relevant code is simply:

local handle = io.readdir("@saltychat/clientloader")

for name in handle:lines() do
    -- files were enumerated here on legacy
end

The same resource and directory layout works on legacy FXServer.

Evidence

This is a regression from the legacy server resource VFS behavior.

The public FXServer implementation mounts the complete physical resource directory under @resource/, rather than only files referenced by the manifest:

auto mountPath = fmt::sprintf("@%s/", resource->GetName());

fwRefContainer<vfs::RelativeDevice> relativeDevice =
    new vfs::RelativeDevice(resource->GetPath() + "/");

vfs::Unmount(mountPath);
vfs::Mount(relativeDevice, mountPath);

Source:

https://github.com/citizenfx/fivem/blob/ba45c32ba5782c784feb939fdf921961b00d9c3f/code/components/citizen-server-impl/src/ServerResources.cpp#L233-L240

The Lua implementation of io.readdir then resolves the VFS device and enumerates it using FindFirst / FindNext.

Source:

https://github.com/citizenfx/fivem/blob/ba45c32ba5782c784feb939fdf921961b00d9c3f/code/components/citizen-scripting-lua/src/LuaIO.cpp

Therefore, on legacy FXServer:

physical resource directory
        ↓
RelativeDevice(resource->GetPath())
        ↓
@readdir_repro/
        ↓
@readdir_repro/clientloader
        ↓
io.readdir()
        ↓
test.lua

On Enhanced b96-ea, the same resource layout/code no longer produces the directory entries.

This matters specifically for server-side resources which dynamically discover files without declaring those files for client download in the manifest.

Additional Context

The original resource uses this behavior to discover Lua files dynamically:

local function listLuaFiles(resourceName, dir)
    local results = {}
    local mount = ("@%s/%s"):format(resourceName, dir)
    local handle = io.readdir(mount)

    if not handle then
        return results
    end

    for name in handle:lines() do
        if name ~= "." and name ~= ".." then
            local rel = dir .. "/" .. name

            if name:match("%.lua$") then
                table.insert(results, rel)
            else
                for _, file in ipairs(listLuaFiles(resourceName, rel)) do
                    table.insert(results, file)
                end
            end
        end
    end

    handle:close()

    return results
end

The relevant original manifest is:

lua54 'yes'

version '1.0.3'

fx_version 'adamant'
author 'Narco City'
game 'gta5'

client_scripts {
    "client/*.lua"
}

shared_scripts {
    'config.lua'
}

server_scripts {
    "server/loader.lua",
    "server/name.lua",
    "server/saltychat_server.lua",
}

escrow_ignore {
    "config.lua",
    "server/name.lua",
    "client/client_open.lua"
}

files {
    "SaltyWebSocket.html",
}

ui_page 'SaltyWebSocket.html'

dependency '/assetpacks'

clientloader/ is deliberately not part of files {} because these files are discovered and handled server-side rather than being distributed as ordinary resource files.

This worked with legacy FXServer and stopped working when moving the same resource to Enhanced Cfx Server.

[Ikonizx]

Same issue as bug 207

[wolfram-cfx]

Is this still a thing with build 98? I wanna make sure its setup depending, because I can not reproduce it locally.

[xalva98]

This is still an issue, here's a minimal repro ressource for you:

What it should do:
load the lua files, the client requests them via event from server => server sends them and then loads via load. However, if the files are not explicitly inside of the manifest they are not discovered. Those files should also not get put inside of the files bracket as this method of loading code is something you could do to protect (kind of) your ressources from people dumping.

server-code-load-test.zip

[xalva98]

Output on enhanced:

║              alva98║ ensure server-code-load-test
[15:06:15] [ info] [citizen-server-i] Stopping resource server-code-load-test
[15:06:15] [ info] [citizen-server-i] Stopped resource server-code-load-test
[15:06:15] [ info] [citizen-server-i] Starting resource server-code-load-test
[15:06:15] [ info] [citizen-server-i] Starting resource server-code-load-test
[15:06:15] [ info] [citizen-server-i] Started resource server-code-load-test
[15:06:15] [ info] [server-code-load] [test] No clientloader .lua files found!

(there's a double print for starting btw)

Output on legacy:

║                Alva║ ensure server-code-load-test
[    c-scripting-core] Creating script environments for server-code-load-test
[           resources] Started resource server-code-load-test
[script:server-code-l] [test] Prepared 1 batches of clientloader code

On Legacy, it discovers the files and creates the batches that should get sent to the client.
This should also technically break ox_lib in enhanced cause they utilize the same discovery method to load code.

[wolfram-cfx]

Thanks, seems like it was filtering out directories.

[Gogsi]

A fix for this bug has been implemented and is available in the August 4 patch. Please try again and let us know if the issue persists. Thanks for your help!

[xalva98]

I sadly can't confirm at the moment as I've reset my PC - but if the ressource from above works on your end then it should be completly fine 👍

[xalva98]

A fix for this bug has been implemented and is available in the August 4 patch. Please try again and let us know if the issue persists. Thanks for your help!

tested it now, seems to work fine now.