This is normal. DOSBOX is theoretically runnable on anything with the file system, SDL port and enough power. This means that it cannot rely on attributes which are specific to one OS (e.g it is reasonable to expect that on any file system there will be available time and name for every file, but this cannot be expected as far as DOS attributes are concerned - these are not universal!).
You may have more luck in future version with support for disk images (everything can be emulated there - at least theoretically, I do not know whether CANADACOW implemented it or not)

Mirek

mirekluza wrote:

This is normal.

Well, I wouldn't call it quite normal. It is true that DOSBox should be runnable on multiple systems, but many users will run it on a Windows platform, on which the 'original' attributes like 'hidden' and 'system' are available. It shouldn't be to much of a problem to add this in the Windows build. For Linux users it will be more of a problem, but I can think of many solutions, amongst which are a seperate FAT16 partition for programs that use attributes, or explicit setting of attributes for certain files in the config file.

JAL

jal, you are right about the need for some kind of a pseudo filesystem (or attribute database) when the attributes can not be easily mapped to the underlying, real filesystem. Putting the attributes-DB in the config file will work for program that only reads/checks the attributes, but it will fail if the program tries to changes the attributes. The changes could be kept in run-time memory so the program will get the expected answer in the DOSBox session, but if run at a later time, the attributes will be right back to what is in the config file.

This kind of problems have been discussed earlier, e.g. how ZIP-archives should be used as DOSBox file systems.

The only *hack* I can think of is to use a file with a non-DOS name (e.g. a file called .ATTRIBS:DB) inside each DOSBox directory. The .ATTRIBS:DB file could then be used by DOSBox to read/write/emulate the DOS attributes.

MiniMax wrote:

The only *hack* I can think of is to use a file with a non-DOS name (e.g. a file called .ATTRIBS:DB) inside each DOSBox directory. The .ATTRIBS:DB file could then be used by DOSBox to read/write/emulate the DOS attributes.

I just thought of another hack: attach the attributes to the filenames, but make sure those aren't passed back to DOS. E.g. a file called "MSDOS.SYS" with attributes A, H and S will have the physical name (on the host file system) "MSDOS.SYS.ahs". A file without extension should have a double dot, e.g. "HISCORE" with attribute A would become "HISCORE..A" on the host file system. Alternatively, instead of letters the hex-code for the attributes could be used.

JAL

While my suggestion is a *hack*, your idea is an *uggly hack*. The beauty of .ATTRIBS:DB is

1. No filename in DOS can include a ':'
2. A dot-directory does usually not show up in file listsing, etc.

Adding filename postfixes looks messy....

Well, something from this would be feasible, but the question is how much needed it is. Apart from Andrea's problem I met an attribute problem just once myself (in the installer for one Windows program unusable in DOSBOX for a different reason) during the whole tiime I work with DOSBOX (since before version 0.56).
I guess that unless somebody submits patch, developers will not bother with this.
Anyway I think there is cleaner solution: CANADACOW implemented image support. I do not know whether attributes are supported or not, but it should not be a big problem to add them (without using any hacks as mentioned above).

Mirek

mirekluza wrote:

CANADACOW implemented image support. I do not know whether attributes are supported or not

They are supported 😉

MiniMax wrote:

While my suggestion is a *hack*, your idea is an *uggly hack*. The beauty of .ATTRIBS:DB is […]
Show full quote

While my suggestion is a *hack*, your idea is an *uggly hack*. The beauty of .ATTRIBS:DB is

1. No filename in DOS can include a ':'
2. A dot-directory does usually not show up in file listsing, etc.

Adding filename postfixes looks messy....

Well, that's a matter of taste, I think. There's no 'beauty' in storing attributes seperate from the file they refer to, and much more difficult to manage when copying files within the host OS. My 'solution', albeit a hack, allows for easy copying/moving of files and even transfering them to different systems without them losing their attributes. Storing the attributes in a seperate file has none of these advantages.

Using diskimages could be a solution, but only if there's ample host OS support for these images, otherwise manipulation outside the emulator would not be possible at all, which is a Bad Thing, imho.

JAL

jal wrote:

Using diskimages could be a solution, but only if there's ample host OS support for these images, otherwise manipulation outside the emulator would not be possible at all, which is a Bad Thing, imho.
JAL

There is DiskExplorer
http://bochs.sourceforge.net/doc/docbook/user/x2291.html