While it works, DataMind Oda reads files and changes them. This page explains how file changes are allowed or denied, what a retry with wider access means, and the messages you may see when a change or a read is refused.
The chat's access mode decides where file changes may happen. It is the same sandbox that stops commands.
| Mode | What a file change may touch |
|---|---|
| Read Only | Nothing. Every change is denied. |
| Workspace Write | Files under the workspace folder, plus some temporary areas the system needs. Each change is checked against the folder again as it runs, so a folder swapped in between does not slip through. This is the default. |
| Full access | Anything Oda can reach. No limits are applied. |
Reading is not limited by these modes: in every mode, Oda can read the files your account can open. To choose the mode, click the mode button in the message box (it shows the current mode) or type /; see Workspaces, files and permissions.
When a write or an edit tries to change a file the mode does not allow, the file sandbox stops that change:
[sandbox: file access denied under <mode> mode].Oda may retry the exact same change once with wider access. It asks you first:
This is the same flow as for a denied command; Command sandboxing and approvals describes it, and Your first task shows the choices and what each answer does.
If you reject it, the change does not run, and Oda continues with the task another way. The refusal is recorded as the user rejected escalating this operation to "danger-full-access".
When nothing can ask you, the wider step does not run either. The request is refused instead of widened, and the step reports no approval service is composed. Nothing is widened without your answer.
When a change or a read is refused because of the file's own state, you see one of these messages. The refused change is not made. A file that is too large for a read to take in is refused with a message rather than shortened.
| Message | What it means | What to do |
|---|---|---|
cannot overwrite existing "<path>" without reading it first | An existing file can only be replaced after Oda has read it in this chat, so it replaces what the file really holds. The memory of a read is dropped when Oda closes, so after reopening a chat, Oda reads a file again before replacing it. | Oda reads the file, then repeats the change. Creating a new file needs no earlier read. |
cannot edit "<path>": file changed since it was read | The file changed outside Oda after Oda read it. The change was refused instead of overwriting the newer text, so nothing was changed. | Oda reads the file again and repeats the change against its current text. The result adds the remedy re-read the file, then retry. |
old_string was not found in "<path>" | The text the edit was to replace does not appear in the file as expected, so the edit did not run. | Oda reads the file again, adjusts to the text as it is now, and retries. |
old_string matched <N> times in "<path>"; provide a more specific old_string or set replace_all to true | The text appears more than once, and the change was meant for one place, so the edit did not run. | For one place, Oda includes more of the surrounding text so the match is unique. To change every occurrence, it uses the replace-all option Replace all matches. |
cannot read "<path>": binary file | The file is not text, and Oda's text tools read UTF-8 text only. | Pictures and PDFs are read by their own kinds of step; see Reading PDFs and Read, write and edit files. For other formats, convert the file to text, or ask Oda to work with it another way. |
cannot read/ | The file is text, but it is stored in a different encoding from the UTF-8 the file tools work in. | Convert the file to UTF-8 and ask again. |
cannot write "<path>": not a regular file | The path is not an ordinary file. It may be a folder or a special entry, and Oda will not write over it. | Point Oda at a file path; a new file inside that folder works. |
A change tried to touch a file outside the chat's limits, and the file sandbox stopped it. Nothing was changed. Allow the wider retry Oda asks for, change the chat's access mode, or point Oda at a folder that suits the work.
One retry of that exact change, with the narrowest wider access that can work. Nothing runs before your answer, the widening covers that one step, and the chat keeps its access mode. The change itself is not altered: the same write or edit is repeated.
No. Wider access always needs your answer, and Oda asks for the narrowest widening that can work. If nothing can ask you, the step does not run.
no approval service is composed mean?The step could not reach an approval prompt, so the wider retry was refused instead of run, and nothing was widened. This happens when nothing in the session can ask you, for example with approval prompts turned off. Ask Oda to make the change inside the mode, or change the chat's access mode.
The text the edit was to replace does not appear in the file as Oda expected, so the edit did not run. Oda reads the file again and adjusts the change to the text as it is now.
The text appears in more than one place, and the change was meant for one. Oda adds more of the surrounding text so the match is unique, or uses the replace-all option Replace all matches when every occurrence should change.
Oda's text tools read and change UTF-8 text only. A binary file gives cannot read "<path>": binary file, and text in another encoding gives cannot read/. Pictures and PDFs have their own kinds of read; for other formats, convert the file and ask again.
The path is not an ordinary file, so Oda will not write over it. It may be a folder or a special entry the system manages. Point Oda at a file: for example, a new file inside that folder.
Yes. A large file is read in a window, part by part, and reading part of a file counts as reading it. Once Oda has read the file in the chat, a change to it is not refused for lack of a read; a file Oda has never read is refused until it reads it.
No. Oda's file steps create and change text; there is no delete, rename or copy step. For those actions, Oda works through a command, which follows the same access mode and file sandbox, or you can do it yourself.