You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
MEGA65_FTP has a mount command which indicates it can mount D81 images from the working directory the user navigated to within the tool. The PC part of MEGA65_FTP will now do direct remote access to the file system to double-check the filename requested by mount actually exists in the directory (so far so good). But then, it sends over a request to the helper application to request to execute the mount command via Hyppo, and this one actually just receives the local filename (without path) and will do set_name and mount hyppo traps. This completely ignores the current working dir of the hyppo and will always try to mount from the CWD that was active on the machine before the helper was started. As the JTAG version of MEGA65_FTP even lacks proper error reporting in case the mount did fail, the user will not even notice it did not mount anything. The user will just be surprised that after quit the image is sometimes not mounted at all.
To Reproduce
Steps to reproduce the behavior:
Power cycle to be in the root directory of the SD
Start MEGA65_FTP via UART
cd to a subdir where a D81 is located
execute mount
quit
Do DIR - the D81 was not mounted as long as no other D81 with that name also resides in the root (then that one actually was mounted)
Expected behavior
The mount command shall make sure it changes the CWD to the correct subdir on the MEGA65 before the mount is executed. This also involves adaption of the communications protocol, as that one only supports sending of the filename itself. It will also need to provide the subdir path.
As a first step, it should be restricted to only allow mount from the root (and do a chdir to root in the helper) so we at least get a consistent behaviour (restricted to mounting from root for now). The final implementation needs to have mentioned directory changing.
The text was updated successfully, but these errors were encountered:
ki-bo
added
new
New report, not classified yet
bug
Something isn't working
and removed
new
New report, not classified yet
labels
Jan 1, 2024
ki-bo
added a commit
to ki-bo/mega65-tools
that referenced
this issue
Jan 1, 2024
Test Environment (required)
Describe the bug
MEGA65_FTP has a mount command which indicates it can mount D81 images from the working directory the user navigated to within the tool. The PC part of MEGA65_FTP will now do direct remote access to the file system to double-check the filename requested by mount actually exists in the directory (so far so good). But then, it sends over a request to the helper application to request to execute the mount command via Hyppo, and this one actually just receives the local filename (without path) and will do set_name and mount hyppo traps. This completely ignores the current working dir of the hyppo and will always try to mount from the CWD that was active on the machine before the helper was started. As the JTAG version of MEGA65_FTP even lacks proper error reporting in case the mount did fail, the user will not even notice it did not mount anything. The user will just be surprised that after quit the image is sometimes not mounted at all.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
The mount command shall make sure it changes the CWD to the correct subdir on the MEGA65 before the mount is executed. This also involves adaption of the communications protocol, as that one only supports sending of the filename itself. It will also need to provide the subdir path.
As a first step, it should be restricted to only allow mount from the root (and do a chdir to root in the helper) so we at least get a consistent behaviour (restricted to mounting from root for now). The final implementation needs to have mentioned directory changing.
The text was updated successfully, but these errors were encountered: