From: Nilgün Belma Bugüner (nilgun@superonline.com)
Date: Wed 21 Apr 2004 - 17:11:34 EEST
Selam,
windows'da uygulanan çözüm kötü bir çözüm; bu çözüm UTF-8'in
yaygın kullanılmadığı, 255 karakterlik karakter kümelerinin
kullanıldığı zamanlarda kullanılmış "hiç yoktan iyidir"
bağlamında bir çözüm. Şimdi UTF-8 var ve libc yerellerinde
hangi harf hangisinin büyüğü/küçüğüdür tanımlanmıştır.
Ayrıca libc üzerinde bu karakter dönüşümleri için bizim
yerelimizi kullanarak yapılan bir geliştirme zaten mevcut:
http://sources.redhat.com/ml/libc-hacker/2003-11/msg00147.html
Bu iletiyi ve bununla ilintili iletileri okursanız, geliştiricilerin
böyle garip çözümlerle uğraşmadığını sanırım göreceksiniz.
Samba için şu yapılabilir. Samba yapılandırma dosyasına
hangi makinaların Unicode bilmeyen makinalar oldukları
belirtilebilir ve bu makinalardan gelen dosya isteklerinde
iconv dönüşümlü dosya isimleri ile işlem yapılabilir.
Bunu yaparsanız faydalı olur. Iconv ile gayet düzgün
yapılan dönüşümü bir windows garabeti ile kirletmeyin derim.
Esen kalın,
Nilgün
Pazartesi 19 Nisan 2004 16:24 sularında, Serdar KÖYLÜ şunları yazmıştı:
> Selamlar..
>
> > Kernel içindekinin userspace ile herhangi bir alakası yok, çünkü tamamen
> > bazı glibc fonksiyonlarının kernel içinde de uygulanabilmesi için
> > kullanılan libraryler. Ki bunlar üstünde yapılacak değişikliklerin
> > pratik olarak herhangi bir samba veya başka sistem üzerinde bir etkisi
> > yok?
>
> Programlar -genelde- bu islevler icin glibc cagrilarini kullaniyorlar,
> kendileri bir strcmp benzeri fonksiyon yazmiyorlar. SMB 2.0 icin boyle
> bir yaklasim vardi diye hatirliyorum, yani kendi strcmp'sine sahipti.
> Ama ne kadar dogru hatirladigimdan emin degilim.
>
> Belki smb icin spesifik cozum olmasada, bu cozum en azindan, galeon,
> evolution, php/apache ve wine icin is yapiyor. smb icin durum biraz
> farkli. O, strcasecmp/strncasecmp kullanmaniza bile izin vermez. Cunku
> SMB/CIFS networklarinda multibyte stringler bolca mevcuttur. Demekki
> baska bir sey dusunmek lazim smb ozelinde. Cok dusunmek gerekmiyor,
> 2.7.x icin (??! = oyle bir sey icin) yapmistim bunu.. Fakat 3.0 icin cok
> fazla deneyimim yok.
>
> Kernel uzerinde fnmatch icin gerekli duzeltme yapilirsa, smb veya mesela
> http oraya "İ" yaziyorum diyor mesela, ama, kernel dosya adinda bunu "I"
> ya ceviriyor. Sonra da acarken, ararken, "İ" istenirse bile "I" olani
> aciyor. Bu da sorunu bir hayli kokten cozuyor, ama guvenilir olup
> olmadigi cok supheli.. Bunu 2.4 icin yapmistim, 2.6 icin hic bakmadim.
>
> Bu mevzular, dagitim olarak TODO listimizde yer aliyor. Simdi, RedHat
> veya SuSE'den bunu beklemek haksizlik olur. Cunku bir hayli experimental
> bir durum. Biz bunu bir iyice deneriz dagitim olarak. Sonucta sorun
> cikmazsa kullaniriz. Iste bu noktada ULUDAG kullanmanin onemi daha cok
> ortaya cikiyor gibi.. Elbette, kimsenin verilerini tehlikeye atamayiz,
> bu testleri "TEST" olarak yapmaliyiz. Simdi biz 6 kisi gunluk isi gucu
> biraksak, testle mesaiyi doldursak bile yeterli olabilir mi? Kaldi ki
> burasi Windows Free Zone.. Ama mesela 100 kisi test etse, soyle win98,
> BSD vs. denese de, hep birlikte bu dertlerden kurtulsak iyi olmaz mi?
>
> > GNU a göndermeden önce biz de görebiliriz değil mi? Buraya patch yapıp
> > yollarsan veya bir web sayfasına upload edersen sevinirim. Mekanizmanın
> > karışık olması çok sorun değil anlayabileceğimi sanıyorum :)
>
> Elbette, bir iki gun icinde SVN access hizmete girecek, bende oraya
> koyarim. Sanirim patch degilde, patch edilmis dosya/uygulama halinde
> olur basta...
>
> Saygi ve sevgiler..