Stored path files
Check a legacy file path
/a/UserFile_exists
Look up a file-record ID using the legacy tenant-prefixed path key.
When to use this endpoint
Use only to reproduce the legacy fname lookup. This endpoint returns a numeric record ID or zero, not a boolean file-system existence check.
Authentication and permissions
Normal requests authenticate with signed API-key fields or a logged-in CRM session. This handler explicitly requires login; CRM2 Files View is not an additional requirement here.
UserFile routes are outside the dispatcher’s File/Files TeamAccess object mapping. They require login where implemented and enforce the tenant rules described here, but do not call File_readGuard or apply the CRM2 Files View check. Do not treat a successful path read as proof of a file-record visibility decision.
Parameters
| Parameter | Type | Required | Description |
|---|---|---|---|
fname | Nonempty string | Yes | The query compares files.url to |
Example request
$id = FM_api('UserFile_exists', ['fname'=>'files/0/1042/abc123']);
Example response
0
Errors and unusual responses
| Response | Condition |
|---|---|
{"error":"not logged in"} | No authenticated tenant context is available. Invalid signed credentials can be rejected by the dispatcher before the handler runs. |
{"error": "missing or invalid parameter: fname"} | fname is missing/blank or PHP-falsy, including "0". |
Legacy application errors may be returned with HTTP 200. Check the decoded response for error, not only the HTTP status.
Behaviour and edge cases
- The successful wire response is a JSON integer: matching file-record ID, otherwise 0. It is not {ok:1}, a filename, content or an array.
- The query has no deleted-row predicate or explicit order and does not call the storage library. A metadata match proves neither live visibility nor available bytes; a missing metadata match does not prove that a backend object is absent.
- Most File_upload results save files/
/ / without a tenant prefix in files.url. This endpoint prepends the tenant, so passing that ordinary relative URL is not equivalent to File_getByUrl and can return 0 for a downloadable file.
Side effects
- Metadata query only; no storage download, access-time update, re-upload command or content hydration.
See it in Fieldmotion
CRM1
CRM1 User profiles, Asset/Job photos and report-design images construct /f/
CRM2
CRM2 User profiles, photos, Job forms, maps and report designers construct /f/
Related endpoints
- File identifiers and downloads compares the path/ID/URL contracts.
File_getFilereturns the original filename and base64 bytes by file ID.