While DataMind Oda works on your computer, it runs commands under a file sandbox, and on Windows that sandbox limits file changes only. This page collects the boundaries a confined command meets on Windows: what the limits cover, what commands can and cannot do, what stays on your folders afterwards, and how a sandbox failure is told apart from a failure of the command itself. For the modes themselves, see Sandbox modes and file policy; for a denied change and the one wider retry, see When Oda is denied access.
partial. Because the boundary covers file changes only, and because of the gaps described on this page, confined steps on Windows record their enforcement as partial, not full; Sandbox modes and file policy explains the two words.| What the command tries | What happens |
|---|---|
| Read a file your account can read | Works, wherever the file is |
| Change or delete files in the workspace (in Workspace Write) | Works |
| Change or delete files anywhere else | Denied |
| Write into the computer's shared temporary folders | Denied; the session's private temporary folder is writable instead |
Write into the shared Public folder (for example C:\Users\Public) | Denied in both confined modes |
Query system information with Get-CimInstance or Get-ComputerInfo | Fails in both confined modes |
| Open a file another program protects for its app container | Fails |
| Capture another program's output through a pipe | Fails |
| Chain commands with a pipe | Works |
Discard output with > NUL or > $null | Works |
| Start in a console of its own | Not available; the command shares the console it was started from |
ConstrainedLanguage), where scripts that use Add-Type, COM, reflection or non-core .NET calls fail. In Workspace Write it starts normally, unless the computer's own policy says otherwise.The sandbox does not take its work on your folders back when a session ends:
A confined command's result can end in one of three ways: the command ran, the mode denied a change, or the sandbox itself failed and the command never ran. Denied changes are covered in When Oda is denied access; this section covers the third case on Windows.
windows-acl-run: and the reported exit code is 127. When that line is present, treat the result as the sandbox failing before the command could run.Reading is not limited in general: a confined command can read any file your account can read. The exception is files another program has protected for its own app container; a confined command cannot open those, even though they open normally for you. The entry belongs to the file, not to the sandbox, and removing it restores access.
Commands that query Windows' management service (WMI), such as Get-CimInstance or Get-ComputerInfo, fail in both confined modes: the confined context is not allowed to ask that service. A few reporting commands, such as whoami, may also fail on some computers; treat those failures as noise about the reporting, not as a problem with the command's work.
The pipe used to capture another program's output is a named pipe, and a confined command is not allowed to open one, so an attempt to capture a started program's output fails with a permission error. Starting a program with shared or discarded output works, and commands chained with a pipe still work.
In Read Only, PowerShell cannot create the probe files its startup check needs, so it starts in its restricted language mode (ConstrainedLanguage); scripts that use Add-Type, COM, reflection or non-core .NET calls fail there. In Workspace Write it starts normally, unless the computer's own policy says otherwise.
The shared Public folder (for example C:\Users\Public) normally lets any signed-in user write. The sandbox removes that allowance for confined commands, so writes into it are denied in both confined modes. In Workspace Write, use the workspace folder instead.
In Workspace Write, the command gets a private temporary folder of its own: its TEMP and TMP settings point there, and that folder is writable. The computer's shared temporary folders are not writable to it, and no session can write into another session's private folder. In Read Only, no temporary folder is writable.
Writing to the NUL device works in both confined modes, so command > NUL still silences output, and PowerShell's > $null works as well. One form, Set-Content NUL, fails in both modes.
The write permission added to the folder stays, and so does a reduced-integrity mark on it; both stay after DataMind Oda closes, and they are kept on purpose so later sessions reuse them. While the mark is there, other programs that run with reduced rights under your account can change files in the folder. A manual attempt to remove the entries does not work; the sandbox manages them.
Because the file has a second name inside the workspace: a hard link is one file with two names, so a change made through the workspace name changes it at the other name too. The limits follow the file, not the folder, and this boundary cannot be closed.
windows-acl-run: line in a command's output mean?It means the sandbox itself failed on this computer before the command could run: the command did not run, nothing was changed, and the reported exit code is 127. Treat it as a sandbox problem, not as a command failure; without such a line, an exit code is the command's own result.