mpremote fs cp can only handle files that already exist
Port, board and/or hardware
Custom RP2040 Pi Pico clone running MicroPython 9.2.8
MicroPython version
Adafruit CircuitPython 9.2.8 on 2025-05-28; Raspberry Pi Pico with rp2040
Reproduction
I'm trying to copy source files to my board, but it fails if a file with the same name doesn't already exist:
mpremote connect id:E464D431C33D2021 fs cp communication.py :
cp communication.py :
mpremote: Error with transport:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
OSError: [Errno 2] No such file/directory: ./communication.py
But if I first create the file...
Adafruit CircuitPython 9.2.8 on 2025-05-28; Raspberry Pi Pico with rp2040
>>> file = open("/communication.py", "w")
>>> file.write("Hello world!")
12
>>> file.close()
>>> file = open("/communication.py")
>>> print(file.readline())
Hello world!
>>> file.close()
... the cp command works perfectly and does what it is supposed to do.
mpremote connect id:E464D431C33D2021 fs cp communication.py :communication.py
cp communication.py :communication.py
[Shows copy progress and finishes without error]
I have also tried to omit the target file name like mpremote connect id:E464D431C33D2021 fs cp communication.py : but it makes no difference.
Expected behaviour
I expect the cp command to create the file on the target board if it doesn't already exist
Observed behaviour
The cp command fails complaining that the file can't be found. I know that, that's why I want to copy it to the unit.
Additional Information
mpremote --version
mpremote 1.25.0
Code of Conduct
Yes, I agree
mpremote romfs deploy: Directory handling is arguably inconsistent with cp -r
Port, board and/or hardware
Board independent. Tested on RP2040
MicroPython version
MicroPython v1.25.0-dirty on 2025-04-19; Raspberry Pi Pico with RP2040
Built with romfs
Reproduction
Issue
$ mpremote deploy foo
where foo is a directory on the PC containing subdirectories
Expected behaviour
The command
$ mpremote cp -r foo :
copies the directory foo with contents and subdirectories to the host. This is consistent with
$ cp -r foo bar
Observed behaviour
By contrast
$ mpremote deploy foo
copies the contents of foo as per
$ cp -r foo/* bar
A typical project might consist of a Python package foo where the executable foo is contained in a directory holding documentation and other resources. The requirement is to copy foo and its contents. Currently this requires a workround involving a temporary directory and a symlink.
Additional Information
Options are either to change this behaviour or provide means of deploying either the directory + contents or contents alone.
Code of Conduct
Yes, I agree