Thanks for your effort. I updated my kernel source from the CVS. The problem with renaming a directory has disappeared. Using ISO-8859-2 charset still does not work. Before I applied the patch, sometimes I had even got a lot of nonsense when listing the contents of a directory (looked like chunks of binary data dumped right onto the terminal). Not the situation seems to have improved a little bit, but the problem with ISO-8859-2 charset still persists. Basically: When I mount without using the iocharset=iso8859-2 option, I can't use certain filenames at all. I get the error "Filename too long" and the syslog says: "Bad UTF-8 character". I consider this normal. When I mount with the iocharset=iso8859-2 option, I can create anything I want, but I won't get it back correctly. Certain characters are even transformed into control symbols like "^O" or "^M". Another problem: when I mount without the iocharset=iso8859-2 option, create some files with national characters, unmount, and remount with the iocharset=iso8859-2 option, I will get filenames that are of completely different length. I would expect filenames to stay the same length even if the charset/codepage are incorrect. If you need, I can send you a tar file with these "ill" filenames. If you untar into onto a udf volume, you will get something quite diffrent from the case when you untar it onto an ext2 or reiserfs volume. Robert Szelepcsenyi -----Original Message----- From: Ben Fennema [mailto:bfennema@attbi.com] Sent: Tuesday, January 07, 2003 6:56 AM To: Robert Szelepcsenyi Cc: packet-writing@suse.com Subject: Re: Various problems with packet writing Robert Szelepcsenyi wrote:
I've done is using UTF-8 and Japanese, and it seemed to work right.
Oops, major bug when dealing with a file name that starts with only needing 8 bits per character and later on needs 16 bits. It starts over, but doesn't reset the location of where its writing the characters into. I havn't tested the fix (its in CVS), but it should be simple enough that even I couldn't screw it up (famous last words). Give it a try and let me know if it behaves any differently for you.
Another problem was that I was not able to use UTF-8 and iocharset at the same time.
Their mutually exclusive. UTF-8 maps directly int 8 or 16 bit unicode.
I would like to know, what takes care for the ISO-8859-x <-> UTF16 transcoding. It seems to me that the system lacks something for ISO-8859-2 and falls back to ISO-8859-1.
the NLS translation tables handle the ISO-8859-x <-> Unicode transcoding. (Which should work exactly the same as VFAT and NTFS do, assuming no more bugs of mine =]) Ben -- To unsubscribe, e-mail: packet-writing-unsubscribe@suse.com For additional commands, e-mail: packet-writing-help@suse.com