CIFS vs SD difference
-
- Top Contributor
- Posts: 655
- Joined: Fri Jan 22, 2021 4:36 pm
- Has thanked: 86 times
- Been thanked: 341 times
CIFS vs SD difference
I tested the core with Crash Bandicoot and Donald Duck Goin' Quackers. Both work quite well from the SD card. No audio in Donald Duck's intro cinematic, but ok. The weird thing, though, is that neither game will launch when I get them from a CIFS mount on my NAS. The exact same files just won't load and I'm stuck on a black screen. Copy them back over to the SD and all is fine again, so they're not getting corrupted in some way during transit. What could cause this? I'm using CUE/BIN files for both.
Re: CIFS vs SD difference
Double check the filename in the cue exactly matches the bin filename, especially case. The CIFS NAS may be case sensitive and the local file system is not.
edit: there were also people that were having issues with permissions on the CIFS server because the PSX currently reuses the 'vhd mount' code path in MiSTer and that opens the bin file RW which may fail depending on how the server is setup.
edit: there were also people that were having issues with permissions on the CIFS server because the PSX currently reuses the 'vhd mount' code path in MiSTer and that opens the bin file RW which may fail depending on how the server is setup.
- aberu
- Core Developer
- Posts: 1199
- Joined: Tue Jun 09, 2020 8:34 pm
- Location: Longmont, CO
- Has thanked: 248 times
- Been thanked: 414 times
- Contact:
Re: CIFS vs SD difference
Make sure you put the boot.rom in your PSX folder on the NAS location too.
birdybro~
-
- Core Developer
- Posts: 385
- Joined: Sat May 23, 2020 12:55 pm
- Has thanked: 42 times
- Been thanked: 415 times
Re: CIFS vs SD difference
The reason is, that the PSX core is "misusing" a drive mapping feature of Mister.
It's usually used for mapping e.g. hard drives in computer cores.
It's usually used for mapping e.g. hard drives in computer cores.
Re: CIFS vs SD difference
The mister code TRIES to detect if the image is writable before it opens it RW, but if you look at your mounted directory all the files are probably mode 0755, so that code ends up opening RW because the file is RW (but not really)
If you look at the mount, it is likely has the options file_mode=0755 and dir_mode=0755 set.
In theory those are fallbacks in the case the server and client do not negotiate UNIX style permissions on the share. I have no idea what magical incantations are required for that negotiation to occur.
As FPGAzumSpass said, this is due to the PSX core's disk mounting being a sort of quick hack just to get data into the core. I assume when full bin/cue support arrives it will be like other cd systems and not even try RW perms.
If you look at the mount, it is likely has the options file_mode=0755 and dir_mode=0755 set.
In theory those are fallbacks in the case the server and client do not negotiate UNIX style permissions on the share. I have no idea what magical incantations are required for that negotiation to occur.
As FPGAzumSpass said, this is due to the PSX core's disk mounting being a sort of quick hack just to get data into the core. I assume when full bin/cue support arrives it will be like other cd systems and not even try RW perms.