VOGONS


First post, by Serious Callers Only

User metadata
Rank Member
Rank
Member

The reason is that very important features of cd mounting are not implemented by mount - i love mount d dir -t cdrom, because i despise wasting space when archiving games, and engine reimplementations (like scummvm, but not only) require the game files on the 'topmost', 'native' filesystem. While many of these files also require a rename, the native filesystem can often deal with it with hardlinks (unlike a iso placed on that native filesystem).

The first is multiple cds and cd change: only implemented in imgmount.
The second is redbook audio, which prevents the usage of this mounting dir as cd trick even with only one cd if the iso has cdaudio.

My suggestion would be moving the 'mount d 'dir' -t cdrom' functionality to imgmount, leave this one as a alias that just redirects to imgmount and implement the external interface in imgmount as requiring a cue file, with a extension of the cue standard like this:
if the 'FILE' tracks in the cue point to a dir (check if it ends with / if you don't want to bother with filesystem checks, just make it consistent) mount it as a dir with the same mechanism as currently on mount.

The redbook audio support (wav/mp3/flac) and cd change support would fall-out of the current code in imgmount.

If you don't want to falsely advertize cues that won't work on cd writing/editing software, just make a 'new' extension for this support that imgmount accepts that is exactly like .cue, but the 'FILE' are actually directories. Name it .zue or something.

I'm aware that sometimes DOS games are sensitive to the format of the isos for copy protection, or race condition bugs purposes, but this is already a 'advanced' feature, that already exists. It just is limited because of those two missing features.