From: Can Erkin Acar (can.acar@pro-g.com.tr)
Date: Tue 20 Apr 2004 - 15:50:13 EEST
Serdar KÖYLÜ wrote:
> Aslen, dosya isimleri konusu bu noktada en tali konu. Daha vahim
> durumlarda soz konusu. Dosya isimleri konusunda, Pure Linux dusununce
> zaten hic bir sorun yok. Sorun case insensitive mevzularda ki dosya
> adlari icin bu malum isletim sisteminin problemi.
>
> Basitce, genel kabul gorebilecek smb/nmb patch'i ile bu sorun
> giderilebilir vede bu yuzden kernel'e vs. bulasmaya gerek kalmaz.
Evet, bu konuda ben de size katiliyorum, ilgili yazilimlar uzerinde
calisilmasi gerek.
> Ama asil buyuk problem su:
>
> HTTP_ACCEPT_ENCODÝNG gzip, deflate, compress;q=0.9
> HTTP_ACCEPT_CHARSET ISO-8859-9,utf-8;q=0.7,*;q=0.7
> HTTP_KEEP_ALÝVE 300
>
> Veya, mozilla'nin eski versiyonlarinda submit butonunun calismamasi :(
>
> Hatta evolution ile:
>
> Updating vfolders for uri: file:///root/evolution/local/Inbox' sırasında
> hata:
> `file' protokolü için alıcı yok
>
> 'file:///root/evolution/local/Inbox dizini açılıyor' sırasında hata:
> `file' protokolü için alıcı yok
>
> Hepsinde cozum, LC_CTYPE=C demek kadar kolay, ama hepsi lanet olsun
> denecek kadar CAN SIKICI. Cozum ise su buyuk harflerle yazdigim kelimeyi
> kucuk harf yapmak kadar berbat bir durum.
Bu konuda bir API eksigi sanirim. i18n'e tabi olacak metinler ile
konfigurasyon ve/veya komut setinin bir parcasi olan 'token' lar
ayni isleme (orn. strcasecmp) tabii tutuluyor. En buyuk sorun da burada.
Bunu programatik olarak cozmek tabii ki mumkun, ancak her uygulama icin
ayri ayri calismak gerekir. Kernel ve/veya glibc tarafinda yapilacak
'genel' bir cozumunun _dogru_ calismasi icin ust paragrafta bahsettigim
token/text ayrimini kendiliginden yapabiliyor olmasi gerek.
Guvenlik problemlerinin bir kisminin bu tip karsilastirmalarin onceden
tahmin edilmeyen sonuclarindan ortaya ciktigini goz onune alirsak (IIS
encoding problemleri, apache/win32 deki guvenlik aciklarinin cogu)
dogru cozumun uygulama kapsaminda yapilmasi gerektigi ortaya cikar.
> Onemli olan bir cozum bulmak. Ve inanin, bu cozum uygulama yazanlari
> ikna etmekten gecmiyor.
Ben sizin kadar kotumser dusunmuyorum bu konuda. Bazi programcilarin
'ulasilmaz' oldugunun farkindayim. Ancak ornek kod gelistirerek, birtakim
temel kutuphaneleri hedefleyerek ve dogru ortamlarda konuyu tartisip
gelistirdigimiz API ve veya ornek kodlari kabul ettirerek bu konuda
gelisme saglayabiliriz diye dusunuyorum.
> ... PostgresSQL tayfasi bunu yapti. Python ayni
> sekilde, ama iste PHP yukarida. evolution asagida. Bir sorun var, bir
> cozum gerekiyor.
Bu konuda size katiliyorum, postgres ve python bence kuvvetli iki baslangic
diger uygulamalar icin yamalar gelistirip bunlari, ornegin ULUGAG dagitimi
icerisinde, yamalanmis halde dagitabilirsiniz. gerekli cabayi gostererek
bu yamalarin zaman icerisinde uygulamalara dahil edilmesi de mumkun olacaktir.
> ... Bu cozum kernelden geciyorsa (ki gecmemesi kuvvetle muhtemel) gecirilmelidir.
Ben genel cozumlerin daha cok problem yaratacagini dusunuyorum. Sihirli bir
"glibc ve/veya kernel" yamasi cok cekici gozukuyor biliyorum, ama boyle bir
cozumun problemin esas kaynagini saklayacagini ve uzun vadede cozumu
zorlastiracagini dusunuyorum.
Iyi calismalar
Can