Is your feature request related to a problem? Please describe.
azure-containerapps-sandbox 0.1.0b4 gives a caller no way to determine that a sandbox entry is a regular file. The data-plane stat response carries isDir and isSymlink, which together prove only that an entry is neither of those. mode is an integer of permission bits with no file-type information — 420 / 511 / 493, i.e. 0o644 / 0o777 / 0o755, with no S_IFREG, S_IFDIR or S_IFLNK.
So a FIFO, socket or device node is indistinguishable from a regular file. Verified against a live sandbox group — a FIFO and a 4-byte regular file, side by side:
{"name":"real.txt","path":"/work/real.txt","size":4,"mode":420,"isDir":false,"isSymlink":false,"modifiedTime":1786412120}
{"name":"pipe", "path":"/work/pipe", "size":0,"mode":420,"isDir":false,"isSymlink":false,"modifiedTime":1786412120}Same mode, both flags false. The only difference is a size of 0, which an empty regular file has too.
This is not merely a classification wart: read_file on the FIFO never returns.
sc.exec("mkfifo /work/pipe", working_directory="/work")
sc.read_file("/work/pipe") # still blocked after 40sA caller that decides what to read from the metadata the service provides will conclude the FIFO is an ordinary empty file, call read_file, and hang. For a library serving an interactive agent, that holds a user's turn open indefinitely, and nothing in the response gives it a way to avoid this.
Describe the solution you'd like
An authoritative entry type on the stat and list payloads, surfaced on FileInfo — either an explicit isRegular boolean alongside the two that already exist, or a single type enum (file / directory / symlink / other) that supersedes them.
An enum would be the more useful shape: it closes the category permanently, where a third boolean leaves the next non-regular type in the same position.
Describe alternatives you've considered
- Infer from
mode. Not possible: the type bits are stripped before the value is sent.
- Infer from
size == 0. Indistinguishable from an empty regular file, which is a legitimate and common output.
exec with test -f before each read. Works, but requires the image to contain a shell — which the file API itself does not, so it fails exactly on the minimal and distroless images where the file API is most useful.- Bound the read with a client-side timeout. What we have done, and it contains the damage rather than fixing it: a hang becomes a refusal after the timeout elapses, and a legitimate slow read of a large file is indistinguishable from a FIFO.
Additional context
Environment: swedencentral, azure-containerapps-sandbox 0.1.0b4, sandbox created from the python-3.13 public disk-image preset. Reproduced against a live sandbox group.
Related but distinct: #48523 reports that FileInfo drops isSymlink and symlinkTarget, which the service does send, and mis-maps isDir. This request is about a field the service does not send at all. Fixing both would let a caller classify an entry entirely through the typed surface.
Is your feature request related to a problem? Please describe.
azure-containerapps-sandbox0.1.0b4 gives a caller no way to determine that a sandbox entry is a regular file. The data-plane stat response carriesisDirandisSymlink, which together prove only that an entry is neither of those.modeis an integer of permission bits with no file-type information —420/511/493, i.e.0o644/0o777/0o755, with noS_IFREG,S_IFDIRorS_IFLNK.So a FIFO, socket or device node is indistinguishable from a regular file. Verified against a live sandbox group — a FIFO and a 4-byte regular file, side by side:
{"name":"real.txt","path":"/work/real.txt","size":4,"mode":420,"isDir":false,"isSymlink":false,"modifiedTime":1786412120} {"name":"pipe", "path":"/work/pipe", "size":0,"mode":420,"isDir":false,"isSymlink":false,"modifiedTime":1786412120}Same
mode, both flags false. The only difference is a size of 0, which an empty regular file has too.This is not merely a classification wart:
read_fileon the FIFO never returns.A caller that decides what to read from the metadata the service provides will conclude the FIFO is an ordinary empty file, call
read_file, and hang. For a library serving an interactive agent, that holds a user's turn open indefinitely, and nothing in the response gives it a way to avoid this.Describe the solution you'd like
An authoritative entry type on the stat and list payloads, surfaced on
FileInfo— either an explicitisRegularboolean alongside the two that already exist, or a singletypeenum (file/directory/symlink/other) that supersedes them.An enum would be the more useful shape: it closes the category permanently, where a third boolean leaves the next non-regular type in the same position.
Describe alternatives you've considered
mode. Not possible: the type bits are stripped before the value is sent.size == 0. Indistinguishable from an empty regular file, which is a legitimate and common output.execwithtest -fbefore each read. Works, but requires the image to contain a shell — which the file API itself does not, so it fails exactly on the minimal and distroless images where the file API is most useful.Additional context
Environment:
swedencentral,azure-containerapps-sandbox0.1.0b4, sandbox created from thepython-3.13public disk-image preset. Reproduced against a live sandbox group.Related but distinct: #48523 reports that
FileInfodropsisSymlinkandsymlinkTarget, which the service does send, and mis-mapsisDir. This request is about a field the service does not send at all. Fixing both would let a caller classify an entry entirely through the typed surface.