I posted a janky workaround that works as long as the profile folder is under the gamefolder. I've since added indexing so I don't have to use FindFile.

Independent confirmation on the same two builds — 1.29.163709 and

1.30.164014.27 — from a server mod that enumerates player record files under

$profile:. Five features silently stopped working. Adding measurements rather

than repeating the repro.

**1. FindFile is not returning nothing. It is searching the server's working

directory.** The prefix is discarded, not rejected. On 1.30, in one run, from a

server whose working directory is its own root:

```

FindFile("*") -> handle, 84 entries (the server folder)

FindFile("addons/*") -> handle, 236 entries

FindFile("$profile:<mod>/Players/*.json") -> NO HANDLE

```

$profile:*, $mission:*, $saves:* and a bare * all return the same

listing. So the mount is not consulted at all, and the remainder of the string

is searched relative to the working directory. That is a narrower statement than

"FindFile is broken", and it predicts every symptom in this ticket.

**2. Only FindFile is affected — $profile: writes still work.** Worth

stating explicitly given this was briefly marked a duplicate of DZEXP-85. On

1.30 we measured creating, writing and reading files under $profile: all

resolving correctly; the mod rewrites $profile:<mod>/Settings.sample.txt on

every boot and reads its settings back from the same mount.

If the intent were to confine mods to the working directory, the write path is

the one you would close first. Instead listing is confined while writing is

not, which is not a coherent sandbox — so this looks like an unintended

consequence rather than hardening.

**3. No live vanilla call site passes a prefixed pattern, which is probably how

this shipped.** There are four FindFile call sites in the 1.30 scripts:

- 2_gamelib/entities/worldsmenu.c:72 — "worlds/*.ent", bare relative.

- 5_mission/gui/newui/videoplayer.c:81 — "video\*", bare relative.

- 4_world/plugins/.../pluginconfigscene.c:112 — FILE_ROOT is declared

"$saves:" but overwritten at line 40 with g_Game.GetMissionFolderPath(),

which is relative. Registered through RegisterPluginDebug.

- 4_world/plugins/.../pluginlocalprofilescene.c:72 — FILE_ROOT = "$saves:",

never overwritten. The only site that would actually pass a prefix, and

PluginLocalProfileScene has zero references outside its own file, so it is

never registered or instantiated.

A regression test built from vanilla usage would not catch this.

**4. The documentation still describes the old behaviour.** EnSystem.c:401

names the three prefixes; :527 and :530 state that Delete and Copy work only

on $profile: and $saves:. 1.30 added a great many [Obsolete] markers

elsewhere and none to FindFile.

**5. A workaround, and its hard limit.** A relative root derived from

GetCLIParam("profiles") works while the profile folder sits under the server

directory, which is the common layout. FindFile refuses an absolute pattern,

and it also refuses ..:

```

FindFile("../*") -> NO HANDLE in the same run where FindFile("*") -> 84 entries

```

So for a -profiles folder outside the server directory there is no pattern

that reaches it, and a mod cannot work around this at all for those servers.

Flagging it in case .. is deliberate and separate from this ticket — it still

bounds how far mods can compensate while this is open.