Quote:
Originally Posted by NiLuJe
The fuse proxy should take care of allowing us to write over in-use files (it creates .fuse-hidden copies that *should* get dropped on file close).
I've never had any issues updating USBNet while checking MRPI's log over USB, in a shell whose binary was being updated, for instance.
(In fact, being able to do that without dropping the USBNet connection, like on legacy FW, was a big incentive when working on MRPI).
|
I have not studied fuse, but I suppose it makes sense when you have rw access to both sides of fuse (i.e. /mnt/us AND /mnt/base-us). There could still be a problem on the Windoze side though, where it arbitrarily writes to the directory structure with no awareness of changes within the device.
I fought this problem with a USB wifi SD card when I had root shell on the SD internal processor WHILE windows was writing to the mounted SD card storage. Files written by either side might disappear, with the most recent file-writer being the winner. They were both fighting over the same directory structure, no doubt.
We might see this same "lost recent data" problem when USBMS and USBNET are loaded at the same time IF both sides are writing to the same files and/or directories -- though persistent sync/fflush after writes would help a lot (though there would still be that stale disk cache problem on reads). If you needed a custom app to do this successfully, it may have to close/sync/reopen the file between transactions, on both sides.
And even on the linux side, there is that whole "4K STDIO non-TTY buffering" issue everybody pulls their hair out over (though "screen" and/or other "fake-PTY utilities" help a lot). But first you need a network stack, and my K1s
ain't got none...
NFS has its benefits (when it works). SMB (in the windows world) is always more than a little "iffy".
However, having USBNET and USBMS definitely has its uses for certain "expert" corner cases, though SCP is a whole lot safer.