File permissions issue?

Is it a matter of not finding the file or finding it but not reading from the file?
If the first I wonder if it could be some problem with case sensitivity in either the filename or directory, especially while mounting the directory. Or even some character that isn't interpreted the same way in Linux like a blank space or punctuation.
For example if you were to try to mount '/media/My Pendrive' and used that without quotations in the config, it would be looking for '/media/My' and not '/media/My Pendrive'
Or if you were to try use '/media/my pendrive' in your config, it would be looking for the case specific '/media/my pendrive', not '/media/My Pendrive'.

If the second, I can't think of anything.
EDIT:
As a thought if the file is small enough, you could try using 'TYPE filename' inside dosbox for windows and linux and see if it looks different.

jmarsh wrote on 2020-08-11, 03:58:

File permissions issue?

This has my vote, but I thought of another one: Linux is case sensitive.

if it helps any, i tried this as root in the past; so it may be the case thing

Thanks for the suggestions, I did some more reasearch after your comments and
looks that it reads wrong data from the file.

The mount looks good, I mount this as drive D: and inside DOSbox all files are there perfectly well and accessible.
After mount all filenames show as uppercase inside DOSbox and the program reads the first config file well
then in reads the second config file and aborts saying "expecting an integer".

If I delete the file or change the name it correctly reports "cannot open file D:\WORK\CONF2.CFG"
when the file is there it reports "expecting an integer"

I can force this error to happen on the win7 DOSbox machine by inserting a non number on the config file,
for example: first line of the file contains: 1<cr><lf> and I make it: a1<cr><lf> and got that error which
makes perfect sense.

(it is not the crlf stuff it is exactly the same on both)

This leads me to the conclusion that on the linux machine this program reads something
strange from the file. But the file is the exact same as in the win7 DOSbox...
Very strange.

Thanks again for your ideas. I know this looks quite odd but if you come up with any ideas
I will be happy... in the mean time I will keep trying variations and changes to see if I bring more
light into this...

Actually I think you may have found the problem.
If I remember correctly Linux doesn't interpret Carriage Return the same as Windows.
So in this case I suspect under Linux it's being read as 1 <some strange symbol> <lf> instead.
Perhaps if you tried creating a config file in Linux instead and see if it gets read correctly?
Or simply remove the carriage return and see if it works.
https://www.networkworld.com/article/3438857/ … s-on-linux.html

Though whether that file would read properly in dosbox/Windows is another matter.

Or the routine that checks the validity of entry (number or not).
Works differently on linux vs windows (or 64 bit vs 32 bit).
So you might want to try the SVN code and compile that on linux if you are capable of doing that.

CR/LF stuff wouldn't matter because DOSBox opens all files in binary mode.

If you're using a build of DOSBox installed by a package manager it's probably really old and out of date.

maybe difference in cpu emulation. maybe dynamic vs normal or something. maybe your app has self modifying code or something.

In addition to trying DOSBox SVN, you may also want to try a few different DOSBox forks. DOSBox ECE, DOSBox-X or DOSBox Staging.

except this is the support forum for dosbox. So don't go recommending/plugging forks when the svn hasn't been tried, as we don't provide support for those.

Wow.
I have built the SVN from source as suggested and now all works 😀 ( Happy camper here... ).

What would be the reason ? (I could not find anything in the list of changes/improvements that hit the eye)
The version I had was the 0.74, was the last build I could find (maybe installed from the soft.manager... not sure).

Great, thanks Qbix.

Qbix wrote on 2020-08-12, 18:23:

except this is the support forum for dosbox. So don't go recommending/plugging forks when the svn hasn't been tried, as we don't provide support for those.

Well, considering this is apparently not a Game, there is no support in any case, right?

jmarsh wrote on 2020-08-12, 11:13:

CR/LF stuff wouldn't matter because DOSBox opens all files in binary mode.

If you're using a build of DOSBox installed by a package manager it's probably really old and out of date.

Well I had some weird issues with batch files in unix format. Luckily there is unix2dos 🤣

Right, but the same files would have given you trouble under windows if they still had Unix line endings. They don't get read differently when you switch OS.

luc7 wrote on 2020-08-12, 21:21:

Wow. I have built the SVN from source as suggested and now all works :-) ( Happy camper here... ). […]
Show full quote

Wow.
I have built the SVN from source as suggested and now all works 😀 ( Happy camper here... ).

What would be the reason ? (I could not find anything in the list of changes/improvements that hit the eye)
The version I had was the 0.74, was the last build I could find (maybe installed from the soft.manager... not sure).

Great, thanks Qbix.

probably the routine used to check for a number. I suspect some FPU call or something similar.

Qbix wrote on 2020-08-13, 16:14:

probably the routine used to check for a number. I suspect some FPU call or something similar.

Yeap, it could be, I know for a fact this software requires FPU in hardware ( 8087 80287 or 80387 on machines before the 486), so all calculations go trough FPU.