Filename and path shenanigans
~~rmapi gives an error when there's a file in the directory that happens to have the exact same name as a directory in that folder.~~
~~For example, if you have this:~~
- Scrybble/
- Test folders/
- Samename/ `/Scrybble/Test folders/Samename/` is a directory
- a notebook
- Samename `/Scrybble/Test folders/Samename` is a file
~~https://github.com/ddvk/rmapi/blob/26960a23d6fc1b7d834d167d983a8f817d2d380d/shell/get.go#L26~~
~~If you do rmapi -ni get "Scrybble/Test folder/Samename" it'll fail with ERROR: 2025/07/07 16:28:23 main.go:85: Error: file doesn't exist.~~
I was wrong. My test-setup was wrong. However this is an issue with stat. It cannot distinguish between file and directory paths.
$ rmapi -ni stat "Scrybble/Test folder/Samename"
{
"ID": "41814299-58ef-4922-8e01-c05d9285fbe6",
"Name": "Samename",
"Version": 0,
"ModifiedClient": "2025-07-07T16:10:31Z",
"Type": "CollectionType",
"CurrentPage": 0,
"Parent": "555d79c4-e0fb-4c58-898f-573062325054"
}
$ rmapi -ni stat "Scrybble/Test folder/Samename/"
{
"ID": "41814299-58ef-4922-8e01-c05d9285fbe6",
"Name": "Samename",
"Version": 0,
"ModifiedClient": "2025-07-07T16:10:31Z",
"Type": "CollectionType",
"CurrentPage": 0,
"Parent": "555d79c4-e0fb-4c58-898f-573062325054"
}
There's also some other weird shenanigans you can do with filenames, this might lead to security errors (maybe?)
For instance, on the reMarkable it's valid to name a notebook ..
But if you try to interact with it:
$ rmapi -ni get "Scrybble/Test folder/Samename/.."
ERROR: 2025/07/07 16:40:56 main.go:85: Error: file doesn't exist
Because it evaluates the .. as a symbol rather than as a filename:
$ rmapi -ni get "Scrybble/Test folder/Samename/.."
{
"ID": "555d79c4-e0fb-4c58-898f-573062325054",
"Name": "Test folder",
"Version": 0,
"ModifiedClient": "2025-07-07T16:10:01Z",
"Type": "CollectionType",
"CurrentPage": 0,
"Parent": "ae6a4f2c-545f-44cd-9e33-3fa449a92a23"
}
Can this go beyond the root folder in rmapi?
I quickly wanted to test whether this would try to resolve to a path below the root folder, but that's handled correctly:
$ rmapi -ni stat ".."
{
"ID": "",
"Name": "/",
"Version": 0,
"ModifiedClient": "",
"Type": "CollectionType",
"CurrentPage": 0,
"Parent": ""
}
$ rmapi -ni stat "../.."
{
"ID": "",
"Name": "/",
"Version": 0,
"ModifiedClient": "",
"Type": "CollectionType",
"CurrentPage": 0,
"Parent": ""
}
And here's one that is actually affecting real users. Someone was using slashes as separators for a date in filenames, like notebook 5/7/2023 etc.
Again, the / gets interpreted as a meaningful path symbol rather than as a meaningless string.
$ rmapi
ReMarkable Cloud API Shell, User: {redacted}, SyncVersion: 1.5
[/]>cd Scrybble/
[/Scrybble]>ls
[f] 3.6 glyphrange
[f] 3.6 highlighted text
[f] 3.6 ocr text
[f] deviceOCR
[f] Log
[f] On computable numbers
[f] pdf_longer
[d] people
[d] Promo
[f] Reflow
[f] RMPP
[f] Scrybbling together
[d] Software
[f] tags test
[d] Test files
[d] Test folder
[f] Test pdf
[f] testing erasers
[f] Text formatting
[/Scrybble]>cd Test\ folder/
[/Scrybble/Test folder]>ls
[f] Crazy/why/slashes/filename
[d] Samename
[f] Samename
[/Scrybble/Test folder]>get Crazy/why/slashes/filename
Error: file doesn't exist
[/Scrybble/Test folder]>
And fails similarly for -ni
$ rmapi -ni stat "Scrybble/Test folder/Crazy/why/slashes/filename"
ERROR: 2025/07/07 16:47:23 main.go:85: Error: file doesn't exist
I think many of these kinds of path names would be illegal on normal filesystems for good reasons, but the difference is that reMarkable's filesystem is actually not a real filesystem but just a render of a JSON document tree which allows them to have all kinds of weird symbols in filenames.
For instance, on my Linux installation I'm absolutely not allowed to name files or directories .. or a/b or . etc. But on the rM this is perfectly acceptable.
I think this leads to a contradiction in symbol resolution logic if you were to satisfice it, consider this folder structure for instance
- a/ -- a folder called "a"
- b -- a file in folder "a" called "b"
- a/b -- a file called "a/b"
No matter how you look at it, it's impossible to resolve what the user meant if they supply the path /a/b.
I can only think of one certain solution:
Make the file and folder arguments separate, so that rmapi stat "path/to/file" "the/name/of/the/file", and rmapi get "path/to/file" "the/name/of/the/file" etc
In that way you can reach the "a/b" file in the root directory like so "/" "a/b" and the "b" file in the "a/"directory like so: "/a" "b"
The stat command signature can be changed to stat <path> [file], resolving to a stat on a directory when it receives only one argument.
I don't know if an interface change is the only surefire way to resolve this issue, but I do think so.
Edit: Well, an interface change isn't necessary, the current approach works for 99% of the use-cases. Could add a get --precise-path or stat --precise path option, or a get --id <id> and stat --id <id> to identify a node unambiguously instead.