On September 20, 2003 02:39 pm, Eric Pouech wrote:
for the time being, we'll be living with two sets of data for device configuration. At the end, of course, only the newly introduced shall subsist.
If you add/delete config options, please send me a note so I can update the options table. I can see you've added a few: Codepage, ReadVolInfo, FailReadOnly, DriveC
Whazzup with these?
Dimitrie O. Paun wrote:
On September 20, 2003 02:39 pm, Eric Pouech wrote:
for the time being, we'll be living with two sets of data for device configuration. At the end, of course, only the newly introduced shall subsist.
If you add/delete config options, please send me a note so I can update the options table. I can see you've added a few: Codepage, ReadVolInfo, FailReadOnly, DriveC
Whazzup with these?
these are not new, they are in current code, and they are even documented on winehq :-) Codepage: if you mount a fs with a given codepage, you need that cp information to transform properly the filenames into unicode. Ideally, we should get this information from OS ReadVolInfo: whether you can try to get the volume information from the attached device, or if you want to get the values from configuration FailReadOnly: Windows allows in some cases to open with write access a file on a read only drive. Wine, by default, when it cannot open a file with write access, tries to reopen without the write access (unix has more decent semantics here). Setting this flag to true, turns off this behavior. DriveC: this is not a config option, it's the default label for drive C, when no decent configuration can be gotten from wine configuration
A+
On September 21, 2003 10:20 am, Eric Pouech wrote:
Codepage: if you mount a fs with a given codepage, you need that cp information to transform properly the filenames into unicode. Ideally, we should get this information from OS ReadVolInfo: whether you can try to get the volume information from the attached device, or if you want to get the values from configuration FailReadOnly: Windows allows in some cases to open with write access a file on a read only drive. Wine, by default, when it cannot open a file with write access, tries to reopen without the write access (unix has more decent semantics here). Setting this flag to true, turns off this behavior.
OK, thanks. Mike, I've added these three as winecfg options. Any objections?
"Eric Pouech" pouech-eric@wanadoo.fr wrote:
Codepage: if you mount a fs with a given codepage, you need that cp information to transform properly the filenames into unicode. Ideally, we should get this information from OS
We already have that information, the support for OS locale is implemented via a Wine extension - CP_UNIXCP. The codepage parameter should go away as soon as all locale information is moved (or duplicated) in ntdll from kernel.
On September 22, 2003 07:08 am, Dmitry Timoshkov wrote:
We already have that information, the support for OS locale is implemented via a Wine extension - CP_UNIXCP. The codepage parameter should go away as soon as all locale information is moved (or duplicated) in ntdll from kernel.
OK, I've dropped it for now. I hope this moving/duplication is in the master plan...
Dmitry Timoshkov wrote:
"Eric Pouech" pouech-eric@wanadoo.fr wrote:
Codepage: if you mount a fs with a given codepage, you need that cp information to transform properly the filenames into unicode. Ideally, we should get this information from OS
We already have that information, the support for OS locale is implemented via a Wine extension - CP_UNIXCP. The codepage parameter should go away as soon as all locale information is moved (or duplicated) in ntdll from kernel.
but couldn't this be different from the charset used for mounting the filesystem ? AFAICS, on VFAT systems, long names are stored in Unicode. The charset in the mount option let you specify the charset for the Unicode -> multi-byte... All filenames will be expressed in this charset (and not the default kernel charset nor your locale)
A+
"Eric Pouech" pouech-eric@wanadoo.fr wrote:
but couldn't this be different from the charset used for mounting the filesystem ? AFAICS, on VFAT systems, long names are stored in Unicode. The charset in the mount option let you specify the charset for the Unicode -> multi-byte... All filenames will be expressed in this charset (and not the default kernel charset nor your locale)
Yes, filesystems might have different codepages (short file names on VFAT), or be pure unicode (NTFS). But native applications don't (and shouldn't) know about that at all. This is handled by the "iocharset" mount parameter.
Dmitry Timoshkov wrote:
"Eric Pouech" pouech-eric@wanadoo.fr wrote:
but couldn't this be different from the charset used for mounting the filesystem ? AFAICS, on VFAT systems, long names are stored in Unicode. The charset in the mount option let you specify the charset for the Unicode -> multi-byte... All filenames will be expressed in this charset (and not the default kernel charset nor your locale)
Yes, filesystems might have different codepages (short file names on VFAT), or be pure unicode (NTFS). But native applications don't (and shouldn't) know about that at all. This is handled by the "iocharset" mount parameter.
but which charset is used when getting the filename (from a directory enum for example). The charset of the mount option, the default charset of the kernel, or the charset of default locale ?
A+
"Eric Pouech" pouech-eric@wanadoo.fr wrote:
but which charset is used when getting the filename (from a directory enum for example). The charset of the mount option, the default charset of the kernel, or the charset of default locale ?
Look at the following line, borrowed from my /etc/fstab: /dev/hda1 /mnt/dosc vfat auto,uid=500,gid=500,ro,noexec,codepage=866,iocharset=koi8-r 0 0
It means that the kernel should use cp 866 for short file names on that drive and translate file names to the local koi8-r encoding for file APIs. It's up to user to make correct assumptions and specify valid mount options.
I.e. it's quite a fair play to assume that the user has correctly configured the system to work with his/her locale.
-
Dimitrie O. Paun -
Dmitry Timoshkov -
Eric Pouech