Ensure proper handling of read-only filesystems #6
Labels
No Label
bug
documentation
duplicate
enhancement
good first issue
help wanted
invalid
question
wontfix
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: Public/misternfs#6
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
An NFS filesystem may be forced to read-only from the server's end. Check how MiSTer deals with that and adjust the script accordingly with mount options as needed. Maybe we should test for it and mount the filesystem read-only from our end as well to keep semantics straight between client and server.
What might be one or more reasons for mounting a network share with read-write permissions? I’m asking this maybe weird question because I’m not sure if we are able to perform any file system modification changes via the MiSTer FPGA interface?
I speculate that some reasons could be:
update.sh
orupdate_all.sh
to network shareWell, or maybe it could be about write operations to the network share from the TTY of MiSTer FPGA system, either via direct keyboard input, or via
ssh
connection, for example?On top of the reasons you already mention, I'd like the backing store for my hard drive images to be writable. I use the Amiga en AO486 cores extensively and they generally expect their hard disks to be read/write.
This may warrant a redesign in a later version that differentiates between arcade/console (mostly) and computers so we can differentiate this. I wouldn't want MiSTer to accidentally fudge up ROM's that don't need to be writable anyway but I do want my hard disks to be writable.
I'm going for the simplest use case first: assume a mount to be read/write and permit things to break on the MiSTer's end if that condition is false.
Another potential tangle: remote file system permissions. MiSTer runs as root. NFS servers generally go full Gandalf on you and won't let you pass. Instead they kick you down to user 'nobody' on their end, which is fine but it will lead to files being read-only even if you're root and your mount itself is read-write. I feel some documentation needs coming up for this script. Either you change the permissions on your files and dirs appropriately or you add a maproot on your exports file to straighten the path for root.