VOGONS

Common searches


First post, by DBob

User metadata
Rank Newbie
Rank
Newbie

Hello all,

The old, never ending story of the CUE/BIN mounting.

Could not load image file: /mnt/DOSBOX/GAMES/XEEN/INSTALL/XEEN1.CUE
MSCDEX: Failure: Invalid file or unable to open.

Meanwhile

  • Files naming is correct (upper-lower case)
  • 755 mode applied to the files, so they are indeed readable
  • Everything is working fine if I mount the very same folder structure from Windows

I also tried to comply a new DOSBox from source, enabling the SDL_Sound, as it was mentioned in some topic, it's required to BIN/CUE handling.
Results were the same with the DOSBox from the distro repo.

Reply 1 of 13, by _Rob

User metadata
Rank Member
Rank
Member

Can you show the content of XEEN1.CUE?

I can assure you that CUE files work just fine with DOSBox on Linux, so I'm afraid it looks like something must be wrong with your setup. Possible reasons I can think of (other then file naming and permissions)
- spaces or other special characters in filenames
- unsupported track format (e.g. mp3 tracks)
- invalid path specified in CUE file

As a general rule, CUE/BIN and any audio tracks should all be stored in the same directory. And the CUE file should ONLY have the filenames without paths specified.

Reply 2 of 13, by DBob

User metadata
Rank Newbie
Rank
Newbie

Thanks for the reply!
Here is the content of the CUE file:

FILE "XEEN1.IMG" BINARY
TRACK 1 MODE1/2352
INDEX 1 00:00:00
TRACK 2 AUDIO
INDEX 0 05:46:13
INDEX 1 05:48:13
TRACK 3 AUDIO
INDEX 0 08:19:52
INDEX 1 08:21:52
TRACK 4 AUDIO
INDEX 0 08:39:58
INDEX 1 08:41:53
TRACK 5 AUDIO
INDEX 0 09:24:04
INDEX 1 09:25:72
TRACK 6 AUDIO
INDEX 0 09:49:51
INDEX 1 09:51:58
TRACK 7 AUDIO
INDEX 0 10:34:11
INDEX 1 10:36:18
TRACK 8 AUDIO
INDEX 0 12:48:66
INDEX 1 12:50:64
TRACK 9 AUDIO
INDEX 0 13:04:26
INDEX 1 13:06:19
TRACK 10 AUDIO
INDEX 0 13:16:41
INDEX 1 13:18:40
TRACK 11 AUDIO
INDEX 0 14:49:24
INDEX 1 14:51:31
TRACK 12 AUDIO
INDEX 0 15:48:14
INDEX 1 15:50:13
TRACK 13 AUDIO
INDEX 0 16:06:65
INDEX 1 16:08:64
TRACK 14 AUDIO
INDEX 0 17:05:06
INDEX 1 17:07:03
TRACK 15 AUDIO
INDEX 0 17:47:08
INDEX 1 17:49:08
TRACK 16 AUDIO
INDEX 0 17:53:31
INDEX 1 17:55:33
TRACK 17 AUDIO
INDEX 0 21:07:62
INDEX 1 21:09:64
TRACK 18 AUDIO
INDEX 0 22:42:49
INDEX 1 22:44:56
TRACK 19 AUDIO
INDEX 0 23:16:58
INDEX 1 23:18:65
TRACK 20 AUDIO
INDEX 0 27:08:50
INDEX 1 27:10:43
TRACK 21 AUDIO
INDEX 0 27:16:31
INDEX 1 27:18:30
TRACK 22 AUDIO
INDEX 0 28:35:54
INDEX 1 28:37:51
TRACK 23 AUDIO
INDEX 0 30:23:38
INDEX 1 30:25:46
TRACK 24 AUDIO
INDEX 0 31:08:71
INDEX 1 31:11:04
TRACK 25 AUDIO
INDEX 0 33:33:31
INDEX 1 33:35:28
TRACK 26 AUDIO
INDEX 0 34:53:54
INDEX 1 34:55:52
TRACK 27 AUDIO
INDEX 0 39:05:45
INDEX 1 39:07:51
TRACK 28 AUDIO
INDEX 0 40:04:21
INDEX 1 40:06:24
TRACK 29 AUDIO
INDEX 0 40:51:08
INDEX 1 40:53:11
TRACK 30 AUDIO
INDEX 0 41:32:48
INDEX 1 41:34:42
TRACK 31 AUDIO
INDEX 0 47:34:38
INDEX 1 47:36:36

Reply 3 of 13, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Is SDL_Sound actually found and compiled in? And if, is this SDL_Sound compiled against SDL 1.2x?

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 4 of 13, by darry

User metadata
Rank l33t
Rank
l33t
DBob wrote on 2021-06-27, 10:29:
Hello all, […]
Show full quote

Hello all,

The old, never ending story of the CUE/BIN mounting.

Could not load image file: /mnt/DOSBOX/GAMES/XEEN/INSTALL/XEEN1.CUE
MSCDEX: Failure: Invalid file or unable to open.

Meanwhile

  • Files naming is correct (upper-lower case)
  • 755 mode applied to the files, so they are indeed readable
  • Everything is working fine if I mount the very same folder structure from Windows

I also tried to comply a new DOSBox from source, enabling the SDL_Sound, as it was mentioned in some topic, it's required to BIN/CUE handling.
Results were the same with the DOSBox from the distro repo.

You probably already checked for this when you mentioned checking case (presumably for XEEN1.CUE), but just in case (no pun intended), is XEEN1.IMG actually in upper case and actually named XEEN1.IMG , not XEEN1.BIN ?
Also, is SELinux enabled and are you hitting any AVC denials in /var/log/audit.log ?

EDIT : Also, what distro are you using ? I just tested mounting a CUE/BIN in Dosbox -0.74-2 from Debian repo (version 10.10) and it worked fine for me .

Reply 6 of 13, by darry

User metadata
Rank l33t
Rank
l33t
jmarsh wrote on 2021-06-29, 23:07:

Make sure the directory holding the bin/cue files is both executable and readable by the current user.

Good to check just in case, but in this specific case, the error suggests that the cue file is being found and read, but the referenced img file isn't .

In the limited tests that I have run, the mscdex error is not shown if the cue file is absent (not there or wrong path) or inaccessible (permissions).

Reply 8 of 13, by jmarsh

User metadata
Rank Oldbie
Rank
Oldbie
darry wrote on 2021-06-30, 00:04:

Good to check just in case, but in this specific case, the error suggests that the cue file is being found and read, but the referenced img file isn't .

In the limited tests that I have run, the mscdex error is not shown if the cue file is absent (not there or wrong path) or inaccessible (permissions).

The cue file gets opened then each data file listed in it gets stat'd. That requires exec permission on the directory holding them.

Reply 9 of 13, by darry

User metadata
Rank l33t
Rank
l33t
jmarsh wrote on 2021-06-30, 23:16:
darry wrote on 2021-06-30, 00:04:

Good to check just in case, but in this specific case, the error suggests that the cue file is being found and read, but the referenced img file isn't .

In the limited tests that I have run, the mscdex error is not shown if the cue file is absent (not there or wrong path) or inaccessible (permissions).

The cue file gets opened then each data file listed in it gets stat'd. That requires exec permission on the directory holding them.

I agree . However, this is likely not the issue in this specific case, as if the cue file and bin/img file are in the same directory and the cue file gets read, but the bin/img file does not, the directory permissions are not the issue . The permissions of the bin/img file could be a problem, but the OP already mentioned checking those (no harm in double-checking).

Reply 10 of 13, by jmarsh

User metadata
Rank Oldbie
Rank
Oldbie
darry wrote on 2021-07-01, 00:02:

I agree . However, this is likely not the issue in this specific case, as if the cue file and bin/img file are in the same directory and the cue file gets read, but the bin/img file does not, the directory permissions are not the issue . The permissions of the bin/img file could be a problem, but the OP already mentioned checking those (no harm in double-checking).

You apparently missed the part where I said the data files get stat'd. That requires execute permission on the directory. It is not performed on the cue file.

I've been a DOSBox developer for the past three years and have encountered this problem before. Please stop assuming I don't know what I'm talking about.

Reply 11 of 13, by darry

User metadata
Rank l33t
Rank
l33t
jmarsh wrote on 2021-07-01, 06:03:
darry wrote on 2021-07-01, 00:02:

I agree . However, this is likely not the issue in this specific case, as if the cue file and bin/img file are in the same directory and the cue file gets read, but the bin/img file does not, the directory permissions are not the issue . The permissions of the bin/img file could be a problem, but the OP already mentioned checking those (no harm in double-checking).

You apparently missed the part where I said the data files get stat'd. That requires execute permission on the directory. It is not performed on the cue file.

I've been a DOSBox developer for the past three years and have encountered this problem before. Please stop assuming I don't know what I'm talking about.

I am not assuming anything about either this issue or about you . I actually tested it . I also included the output in Dosbox when the mount attempt fails due to lack of execute permission on the folder containing the cue and img files . As you can see, the error is not the one that the OP is reporting . I was running Dosbox's graphical output redireced to an X server running under Windows (Xming) while testing, which explains the Windows-like GUI elements .

After running chmod o+x on /srv/dev-disk-by-label-DATA3/DATA3_rw/temp/popple and starting dosbox and trying to mount cue :

bob@openmediavault:/srv/dev-disk-by-label-DATA3/DATA3_rw/temp$ strace dosbox 2>&1 | egrep "popple.cue|popple.img"
stat("/srv/dev-disk-by-label-DATA3/DATA3_rw/temp/popple/popple.cue", {st_mode=S_IFREG|0664, st_size=769, ...}) = 0
stat("/srv/dev-disk-by-label-DATA3/DATA3_rw/temp/popple/popple.cue", {st_mode=S_IFREG|0664, st_size=769, ...}) = 0
openat(AT_FDCWD, "/srv/dev-disk-by-label-DATA3/DATA3_rw/temp/popple/popple.cue", O_RDONLY) = 10
read(10, "FILE \"popple.img\" BINARY\r\n TRAC"..., 8191) = 769
stat("popple.img", 0x7ffc67456550) = -1 ENOENT (No such file or directory)
stat("/srv/dev-disk-by-label-DATA3/DATA3_rw/temp/popple/popple.img", {st_mode=S_IFREG|0664, st_size=598318224, ...}) = 0
openat(AT_FDCWD, "/srv/dev-disk-by-label-DATA3/DATA3_rw/temp/popple/popple.img", O_RDONLY) = 11
openat(AT_FDCWD, "/srv/dev-disk-by-label-DATA3/DATA3_rw/temp/popple/popple.cue", O_RDONLY) = 10
read(10, "FILE \"popple.img\" BINARY\r\n TRAC"..., 8191) = 769
stat("popple.img", 0x7ffc67456600) = -1 ENOENT (No such file or directory)
stat("/srv/dev-disk-by-label-DATA3/DATA3_rw/temp/popple/popple.img", {st_mode=S_IFREG|0664, st_size=598318224, ...}) = 0
openat(AT_FDCWD, "/srv/dev-disk-by-label-DATA3/DATA3_rw/temp/popple/popple.img", O_RDONLY) = 12

After running chmod o-x on /srv/dev-disk-by-label-DATA3/DATA3_rw/temp/popple and starting dosbox and trying to mount cue :

bob@openmediavault:/srv/dev-disk-by-label-DATA3/DATA3_rw/temp$ strace dosbox 2>&1 | egrep "popple.cue|popple.img"
stat("/srv/dev-disk-by-label-DATA3/DATA3_rw/temp/popple/popple.cue", 0x7ffcbb26c9b0) = -1 EACCES (Permission denied)
stat("/srv/dev-disk-by-label-DATA3/DATA3_rw/temp/popple/popple.cue", 0x7ffcbb26c9b0) = -1 EACCES (Permission denied)

output.png
Filename
output.png
File size
11.3 KiB
Views
292 views
File license
Public domain

EDIT: Corrected typo

Reply 12 of 13, by DBob

User metadata
Rank Newbie
Rank
Newbie

Is SDL_Sound actually found and compiled in?

Yes, it is.

And if, is this SDL_Sound compiled against SDL 1.2x?

I don't know. How can I check it?

EDIT : Also, what distro are you using ? I just tested mounting a CUE/BIN in Dosbox -0.74-2 from Debian repo (version 10.10) and it worked fine for me .

Same here, but without success.

Make sure the directory holding the bin/cue files is both executable and readable by the current user.

I've made sure earlier the directories are readable, but I had no idea, they have to be executable as well. I just tested it.
It works!

It made me wonder, why this is only an issue for the CUE/BIN mounting only. But for now, I already added modified everything in recursive to be executable. I'll try my other images as well.
Thanks!

Reply 13 of 13, by darry

User metadata
Rank l33t
Rank
l33t
DBob wrote on 2021-07-03, 19:26:
Yes, it is. […]
Show full quote

Is SDL_Sound actually found and compiled in?

Yes, it is.

And if, is this SDL_Sound compiled against SDL 1.2x?

I don't know. How can I check it?

EDIT : Also, what distro are you using ? I just tested mounting a CUE/BIN in Dosbox -0.74-2 from Debian repo (version 10.10) and it worked fine for me .

Same here, but without success.

Make sure the directory holding the bin/cue files is both executable and readable by the current user.

I've made sure earlier the directories are readable, but I had no idea, they have to be executable as well. I just tested it.
It works!

It made me wonder, why this is only an issue for the CUE/BIN mounting only. But for now, I already added modified everything in recursive to be executable. I'll try my other images as well.
Thanks!

Glad it worked .

Execute permissions are required on a directory in order for access to the files contained in it to be allowed . It's still a bit strange that you were hitting the "MSCDEX: Failure: Invalid file or unable to open." error as having "FILE "XEEN1.IMG" BINARY" being set in your cue files implies that that the XEEN1.IMG is in the same directory as the CUE file and if that directory's permissions were not set to allow execution for the user running DOSBox, the CUE file would not have been readable, which would give a different error message .

I tried reproducing the issue that you mentioned using even the latest SVN build, but am unable to do so (see below). So either there is something different between your setup and mine or there is some misunderstanding as to what was occurring on your end.

Without exec permission on directory :

no_exec_perm.png
Filename
no_exec_perm.png
File size
44.65 KiB
Views
192 views
File license
Public domain

With exec permission on directory :

with_exec_perm.png
Filename
with_exec_perm.png
File size
55.65 KiB
Views
192 views
File license
Public domain