See bug #55268 to see what we have done for old hotplug system.

See also bug #62785.

According to bug #62785 we should use "utf8=true" instead of "iocharset=utf8"
in the case of UTF-8 because "utf8=true" works without a warning.

But the current problem is that hotplug.subfs.functions is obsoleted in SL9.3.
We can't fix this issue in this script like what we have done for SL9.2.

And I couldn't understand how does current hotplug subsystem work, especially
where the removable media is actually mounted.

btw, we should use utf8=true only for UTF-8 locale combined with vfat/fat
filesystem. iocharset=xxx should always be used for other locales and filesystems.

Zhe> But the current problem is that hotplug.subfs.functions is
Zhe> obsoleted in SL9.3.  We can't fix this issue in this script like
Zhe> what we have done for SL9.2.

Yes.

Zhe> btw, we should use utf8=true only for UTF-8 locale combined with
Zhe> vfat/fat filesystem. iocharset=xxx should always be used for
Zhe> other locales and filesystems.

Yes, that's true. utf8=true is a special case.

This is IMHO a problem of subfs, reassign this bug

*** Bug 78101 has been marked as a duplicate of this bug. ***

How about this bug? Is it fixed in current stable?

I can fix the utf part for fat/vfat by default and/or through HAL information 
(volume.policy.mount_option.iocharset=utf8 = true/false), no problem. 

I can add also a check of HAL for a other than utf8 iocharset option, set by 
user through a fdi-file to the submount binary.

But for stable was planed a new solution for mount. But I'm not sure if there 
anything happens.

Please try to fix this for the next SuSE Linux release!

It is very annoying that this was broken again in SuSE Linux 9.3.

Currently the submount binary called by hal mount never a device with utf8=true 
or iocharset=??? . I'm not sure if this is really a problem, but I can as I sad 
add this to the binary. But as I also sad: I'm not sure if this is maybe lost 
work if there is a other solution for 10.0.

@Adrian: what should we do for 10.0?

first of all we should use the mount options provided by HAL. It is disabled 
currently because they was mostly wrong and prevented a successfull mounting. 
This should get fixed. 
 
The new solution is only an extended solution, so no work here will be lost. 
 
 

o.k. I add utf support to the submount binary like the fix for sync option. 

Is it really needed to mount the other devices with iocharset option (besides 
for fat/vfat) in 10.0? Is there a case where a hotplugged device is mounted with 
a iocharset other than the system iocharset?

For general iocharset option I can do this:
- add a function to hal to check the current iocharset (like in hotplug.subfs.
functions) and add a entry to the machine root-entry in hal (../Hal/devices/
computer).
- check by mount for the hal entry and if there is maybe a other entry (maybe 
merged by a fdi file) for the volume and use them.


Other question: Who add on STABLE Snapshot the /media/dvdram entry to fstab? If 
this was yast: Is this really needed since hal/submount mount the CD/DVD 
volumes? Same problem for the dirs in /media. Must Yast changed?

Hi, the following is my understanding by reading the source code:

1) Now we have four kernel module options for encoding issue: iocharset, nls,
codepage and utf8.
2) As I know the following filesystems need encoding setting:
  * fat/vfat:
    support codepage, iocharset and utf8 options. codepage is for short file
name, while utf8 and iocharset are for long file name. utf8 has higher priority
than iocharset, but iocharset is necessary even utf8 is used. So for fat/vfat,
all this three options should be set according to the current locale setting.
  * ntfs:
    support iocharset and nls. iocharset is obsoleted by nls. utf8 is not
supported by ntfs. So use nls for ntfs. 
  * ISO9660/JOLIET:
    support utf8 and iocharset. For utf8 locale use either utf8 or iocharset.
For other locale iocharset is necessary.
  * UDF:
    same as ISO9660.
  * Other filesystems: smbfs, cifs, ncpfs, jfs, befs all support iocharset or
codepage options.

3) the default kernel codepage and iocharset are set to "cp437" and "iso8859-1"

So you see, it's not so easy. We must use appoprate option(s) for different
filesystems and locale settings.

Is there any progress on this bug? I think we should fix this bug asap. It's so
anonying.

According to comment #13, we need implement the following features:

- add a function to hal to check the current iocharset (like in hotplug.subfs.
functions) and add a entry to the machine root-entry in hal (../Hal/devices/
computer).
- check by mount for the hal entry and if there is maybe a other entry (maybe 
merged by a fdi file) for the volume and use them.

So I think we need patch both hal and submount (mount-subfs.c).

If you are too busy to implement it, I'd like to have a try.

I'm thinking about whether it's suitable to add an entry to hal for current
iocharset (locale ctype). Because hal stands for hardware abstract layer
(right?), while iocharset information is nothing to do with hardware.

Ok, I tried to fix this issue by patching hal and submount. The patch and
updated files will be attached.

I did the following work:

1) hal-0.5.4cvs/hald/linux2/osspec.c was patched to attach property
"system.default_iocharset" to "/org/freedesktop/Hal/devices/computer" device,
according to the current locale.
2) modify rc.hal to load /etc/SuSEconfig/profile or /etc/profile.d/lang.sh, so
that hald could get current locale setting.
3) modify mount-subfs.c in submount package to get "system.default_iocharset"
property and use it as value of iocharset mount option.

I use only "iocharset" option here, because submountd will handle all exceptions
when iocharset is not valid.

I tested it on SUSE 10 beta 1, tt worked correctly.

Created attachment 45851 [details]
Patch to export iocharset option according to system locale setting.

Created attachment 45852 [details]
new mount-subfs.c to make use of the iocharset information exported by hal.

Created attachment 45853 [details]
New rc.hal to load system language setting before launching hald.

Please review this solution and fix this bug asap.
There is only one issue that iocharset=utf8 on vfat will cause a kernel warning.
See bug #60085.
I'll try to patch submount to get rid off this warning.

Created attachment 45857 [details]
Patch to get rid off kernel vfat warning when using iocharset=utf8 option.

See bug #60085 and #62785 for details of this issue.

With patches and updated files in comment #18, comment #19, comment 20 and
comment #22, this bug could be fixed completely.

I tested it on SUSE 10 beta 1 i386 system, it worked without problem, no matter
whether the system locale is UTF-8 or not.

to comment #16: We can't add this this HAL. The reason: if the someone change e.
g. with yast the language of the system hal never get a information about this 
and hence hal provides wrong information. We need to move the check to mount-
subfs.c (patch rc.hal isn't needed)

to comment #17: IMHO submountd does not handle all exceptions when iocharset 
option is not valid. For example: iocharset for ntfs is depricated. We must use 
nls for ntfs and submount never check or change this.

to patch of mount-subfs.c: please use getpac for the last version of the file .
.. you removed a important codepart. :-)

I'm not sure if we need to patch submountd-0.9/submountd.c because the fstype 
check in mount-subfs.c is not up-to-date. HAL should detect also ext2 and vfat 
correct, so we should change the mountoption for vfat as for ntfs

So, could you please help fix this issue? Or if you have no time, could you
please send me the latest version of submount so that I could try to fix it again.

And for ntfs issue, we could handle it within submountd just like vfat. Because
it's much simpler. Then we could use only iocharset within mount-subfs.c to make
it as simple as possible.

Ok, another try.

A script submount-get-iocharset was added to print the corresponding iocharset
of current locale setting.

A patch for mount-subfs.c to get iocharset value by invoking
submount-get-iocharset script.

So that patching hal is not necessary anymore.

Created attachment 45930 [details]
submount-get-iocharset script to print the corresponding iocharset value of current locale.

Created attachment 45931 [details]
patch for mount-subfs.c to get iocharset value by invoking submount-get-iocharset script.

submount-get-iocharset should be put into /usr/sbin

Sorry for the delay to comment #26.

The new version (from #27 - #29) looks good for me. I would add this to the 
submount package if it's o.k. for you. 

Thanks for the patch.

Thanks.

Please merge the patch in comment #22 as well. It replaces iocharset=utf8 by
utf8=true for vfat filesystem.

And I think using iocharset for ntfs is ok at least for now. I'll try to fix the
ntfs issue if you think we should get rid off the "iocharset obsolete" warning.

Yes, I merge also this patch. 

For vfat and ntfs I added also a check in hald-block-subfs to try to create the 
correct mount command. But if it fail we have the patch from #22 as fallback

Ok thank you very much. When could I get the updated package from dist.suse.de?
That's the only way I get new package.

for which arch did you need the package? I add the rpms to my export (~dkukawka/
Export/submount)

How can I get it? I just need source rpm, so that I could build it by myself.
I'd like to help you test it so that we could close this bug if it's ok.

I mail you a source rpm directly! 

mailed the rpm . I close the bug now. If there are any problems with the fix, 
please reopen the bug

I must reopen: you can't mount ext3 and xfs with iocharset=utf8. This is not a 
option for them!

se above

fixed:

-------------------------------------------------------------------
Sat Aug 13 06:56:37 CEST 2005 - dkukawka@suse.de

- fixed bug #74614 again:
  * only this filesystems support iocharset: vfat (if not urf8).
    udf, iso9960, jfs and ntfs use nls instead of iocharset
  * other filesystems e.g. reiserfs, ext* and xfs don't support
    this option and can't be mnounted with iocharset !!!

I have another patch for submount to fix a potential iocharset issue.
And I found in mount-subfs.c that you removed iocharset option in fstype==NULL case.
I just wonder in what kind of situation that fstype (volume) could be NULL?
I think we should use iocharset option even in such situation, and let submountd
to  decide whether iocharset should be used or not.

Created attachment 45961 [details]
Patch for submountd to ensure correct mount options for any filesystems.

to #41: I think this is the only one correct behavior. If HAL call hald-subfs-
mount without to have a fstype for the added volume we have already a problem. 
Since I saw the problem with xfs and ext* to mount with iocharset (no accessable 
mount, hanging processes ...) I prefer to mount a volume with unknown fstype 
without iocharset options. In such cases the chance is greater to get a 
succsessful mount without iocharset. Better mount with default than no mount. 

I'll review the attached patch

With the patch in comment #42, the xfs and ext* issue could be avoided, because
submount will remove iocharset option when the fstype doesn't support it.

submitted new package for beta2

I found a typo in mount-subfs.c:

--- mount-subfs.c       2005-08-21 04:28:06.000000000 +0800
+++ mount-subfs.c.new   2005-08-27 10:46:01.000000000 +0800
@@ -533,7 +533,7 @@
                 snprintf( cmd, MOUNT_LENGTH,
                           "/bin/mount -t subfs -o %snosuid,nodev,exec,utf8=true
%s \"%s\"",
                           subfs_type, device_file, mount_point );
-            } else if (!strcmp( fstype, "udf" ) || !strcmp( fstype, "iso9960" ) ||
+            } else if (!strcmp( fstype, "udf" ) || !strcmp( fstype, "iso9660" ) ||
                       !strcmp( fstype, "vfat" ) || !strcmp( fstype, "jfs" )) {
                 snprintf( cmd, MOUNT_LENGTH,
                           "/bin/mount -t subfs -o
%snosuid,nodev,exec,iocharset=%s %s \"%s\"",

thanks for the report, fixed commited should be in next beta