HOVD 2015 - Kedvenc fájlrendszer

HUP

btrfs
7% (69 szavazat)
ext2, ext3, ext4
65% (613 szavazat)
exfat
1% (7 szavazat)
hfs, hfs+
2% (20 szavazat)
jfs, jfs2
1% (8 szavazat)
ntfs
7% (61 szavazat)
reiserfs, reiser4
1% (13 szavazat)
ufs, ufs2
1% (8 szavazat)
xfs
5% (51 szavazat)
zfs
9% (88 szavazat)
Összes szavazat: 938

( carlcolt | 2015. 12. 14., h – 19:07 )

Igazabol amit hasznaltam, az mind szar:

hfs+: lassu. Merhetoen lassabb mint a tobbi. Mas baj amugy nincs vele.
ntfs: nincs case-sensitive fallbackje (good luck git checking out egy eddig csak Linuxon fejlesztett projektet), nem lehet ':' a fajlrendszerben
ext4: ha keves az inode, formazhatod ujra
reiserfs: aramszunet -> jo esellyel viszlat adat

A tobbit csak minimalisan hasznaltam, nem volt eselye ilyeneknek elojonni, azt majd kiegeszititek.

ZFS-re szavaztam annak ellenere, hogy kb addig hasznaltam, amig csinaltam egy particiot FreeBSD-nek.

Update: utananezve lassabbnak tunik, mint a HFS+, de sebaj, az NTFS-t akkor is eselye van megverni, ott marad a szavazatom, mert azt meg egyenesen utalom.

Ha egy filerendszer (filerendszer!) 8G memet igenyel default, az nem filerendszer. Tudhat barmennyi dolgot (anno a "Z" az Ultimate lett volna), akkor is csak spec. esetben hasznalnam. Egyszeruen nem tudom elkepzelni, mire fel kell neki ennyi (meg ha amugy szimpi is, amiket olvastam rola, jo cucc)

Mondjuk, nem egy altalanos gepre vagy szerverre, hanem direkt storagere viszont jo lehet.

--
http://www.micros~1
Rekurzió: lásd rekurzió.

Biztos, en regimodi vagyok, igy szoktam meg. De nem zavar a "fájl" irasmod sem. Zarojelben azert irtam, mert _csak_ egy bizonyos resze egy rendszernek. Konkretan az se dobna fel, ha pl. a drivereknek kellene 8G memoria. Vagy a GUI-nak. Szoval lehet akar 64g memoria is a gepmben, zavarna, ha abbol 8g-t csak a filerendszer vinne el. De ahogy feljebb es lejjebb is mondtam, storagenek (azaz celgepnek) mar oke, ertheto, de altalanos felhasznalasra kisse soknak tunik, hogy cskaa filerendszer egyen 8G-t.

Asszem, tobbszor nem irom le.

--
http://www.micros~1
Rekurzió: lásd rekurzió.

Ez a 8GB default memória igény a ZFS-nél, ez honnan jön? Csak mert van olyan gépem, amin ZFS-t használok vagy másfél, 2 éve, de mivel a gép háza nem a Pasa parkban lakik, azóta se nőtt meg a benne levő memória 6GB-ról. És eddig még egyetlen egyszer nem volt memóriaelfogyásom abban a felállásban. Emlékeim szerint a dedup kapcsán emlegettek nagy memóriaigényt. De tény, nem nagyon olvasgattam utána, beállítottam, oszt megy.
(Amúgy ami még rémlik, hogy a TB-nyi kapacitás függvényében nő kb lineárisan a memóriaigénye, szóval ez akkor valami othoni és kisirodai mércével mérve nem kicsi sztoridzs :-) esetén állhat fenn.)

hat, freebsd 8 es 9 eseteben ha CSAK 4GB ram volt az egyebkent nem nagy terhelesu gepben, akkor azt allandoan megette a zfs, es az oom_killer irtotta a processeket... kellemetlen volt egy levelezoserver eseteben...

legfrisebb tapasztalat, hogy otthoni nas-ban 8 GB RAM van, par honapja frissitettem freebsd 9.x -rol (hibatlanul mukodott!) 10.1 -re, es bizony csomoszor meghal a gep, logokbol arra tudok kovetkeztetni, hogy zfs felzabalta a memoriat, es az oom_killer mukodesbe lepett...

tehat 2 eves rendszer ala valoban eleg volt meg a 6GB RAM zfshez, ma mar a 8GB annyira de annyira minimum, hogy ha valami meg elkezd egy kis memoriat kerni, akkor jon az oom_killer...

en is bosszus vagyok ezert, nehogy ma' az otthoni kis fostaliga fileserverbe 16GB RAM kellejn, f.szert nem eleg a 8GB...

amit te mondasz, hogy x TB kapacitashoz x GB RAM kell, az a deduplikacio eseteben okolszabaly, ilyen altalanos megkotes/szabaly nincs alapesetben.

komolyan azon gondolkozom, hogy tolom le a freebsd -t az otthoni fostos NAS-rol es teszek fel valami ubuntut ext -re mdadm -mel, azt csokolom... de hat evekkel ezelott nem veletlen valtottam ubuntu+mdadm komborol freebsd+zfs -re. :)

10.1 -nél lett problémám nekem is.
valami valtozott az ARC teruleten.
lehet, hogy 10-2-ben mar megint jo, majd lefrissitem arra.
nem tartom normalisnak, hogy 8GB RAM-nal az ARC ugy felzabalja a RAM-ot, hogy az oom_killer kezd el gyilkolaszni, ahelyett, hogy inkabb csokkentene az ARC meretet...

Érdemes limitálni az ARC méretét a zfs modul betöltésekor, rendszerindításkor.
Linux alatt az spl és a linux memóriakezelése közti interferencia képes arra, hogy az ARC méretének dupláját lefoglalja, ami gondot okozhat. Freebsd alatt nem tudom, biztos saját problémák vannak.
Egyébként nekem is működik mini gépen 4GB memóriával (linux) a natív zfs.

--------------------------
"Nicolas, cage them!"

Én banana Pi-n használom a ZFS-t. (ennek 1GB memóriája van, mint az közismert :)
A hozzá kötött 1TB-os SATA disk 70%-ig van kihasználva (köztük laptop backup is, így sok millió fájl is van).

Persze nincs dedup, de az egy külön történet... tömörítés viszont van olyan dataset-en ahol ennek van értelme.

milyen verzio a freebsd?
4GB (vagy 2GB?) RAM alatt a boot folyaman egyebkent ki is irja neked, hogy "warning: too low mem, fs prefetch is disabled, to enable blablabla" szeru figylemeztetest.
ugy gondolom, teged azert nem erint a dolog, mert X GB alatt automatikusan kikapcsolja a prefecth-et a freebsd, es igy nem zabalja fel az ARC a RAM-odat.

4GB alatt mondja ezt. De szóltam neki, hogy meg se próbálja így már nem panaszkodik.

Be kell állítani, hogy mennyi memóriát használjon:
pl.
https://www.freebsd.org/doc/handbook/zfs-advanced.html
https://wiki.freebsd.org/ZFSTuningGuide

% uname -a
FreeBSD bananapi 11.0-CURRENT FreeBSD 11.0-CURRENT #4 r292894M: Wed Dec 30 11:51:27 CET 2015 root@bananapi:/bananapi/build/usr-obj/bananapi/build/usr-src/sys/A20-cstamas arm

köszi, ezeket ismerem.
két dolog: 1.) miért nem állítja be magát?!?! ha fogy a RAM, a kernel miért nem az ARC cache-ból dob ki blokkokat, miért engedi ehelyett, hogy elfogyjom a RAM?!?!
2.) a ZFSTuningGuide-ban is ez van írva: "
amd64

NOTE (gcooper): this blanket statement is far from true 100% of the time, depending on how the system with ZFS is being used.

FreeBSD 7.2+ has improved kernel memory allocation strategy and no tuning may be necessary on systems with more than 2 GB of RAM."

Nem ismerem az implementációs részleteit a freebsd zfs-nek és a memóriakezelésének.

Valószínűleg idővel egyre kevésbé kell kézzel hozzányúlni.
Azért az arm architektúra legalábbis az banana pi ami nekem van új dolog freebsd-ben és vannak gyerek betegségei még.

Jelenlegi helyzet az, hogy ha valakinek van sok memória a gépében akkor hagyhatja defaulton a beállításokat. Ha 1GB vagy annál kevesebb akkor kézi beállítás szükséges.

"Jelenlegi helyzet az, hogy ha valakinek van sok memória a gépében akkor hagyhatja defaulton a beállításokat. Ha 1GB vagy annál kevesebb akkor kézi beállítás szükséges."
write-only? arról beszélek, hogy 8GB RM mellett felszabalja az ARC az osszes memoriat, es jon az oom_killer.

Javitom. Szoval engem az zavar, hoyg tudomasom szerint a SUN _altalanos_ filerendszernek tervezte. Ilyen szempontbol zavaro a tobb giga mem igeny.
Persze lehet, hogy nem asztali gepekbe, hanem Solaris system ala, oke. Az is lehet, hoyg en olvastam felre valamit es megsem az volt a vagyuk, hogy a vilag osszes letezo gepen ZFS legyen. Lehet, hogy a kezdetekkor par megaval is megelegedett. Nem tudom.

Meg persze ott van az is, hogy itt nem a legjobb fs-re szavazunk, hanem a kedvencre es a tudasa alapjan nekem is nagyon szimpatikus.

Szoval ennyit akartam csak az utolso szo jogan elmondani, johet a kovezes.

--
http://www.micros~1
Rekurzió: lásd rekurzió.

Illetve nem csak az implementáció, hanem a felhasználó esetleg nem hangolja a rendszerét, hanem belecsap a lecsóba, esetleg nem is ismeri és azt várja, hogy úgy megy, mint az ext4.

Dedupot pedig ne használjon senki nyomós ok nélkül, lz4-et pedig bátran.

--------------------------
"Nicolas, cage them!"

nem kell túlzásba esni, nem kell ehhez AI.
nem egy nagy algoritmus lenne az, hogy "if max_mem == ARC_size then drop_ARC_partial();"
nem, ehelyett mi van? az van, hogy felzabálja az össes RAM-ot és az oom_killer elkezdi kilődözni a processeket.
hozzáteszem, az oom_killer is inkább dobathatná el ilyenkor az ARC-ot, mint random kilövöldözi a processeket...

Ez Linuxizmus. Az ARC A betűje az "adaptive" kifejezést takarja, és olyan rendszereken, amire nem gumipókkal erőltették rá a ZFS-t, ez OOTB menni is szokott szépen. Az OOMkilller meg eleve baromság _szerintem_, mivel az OS létjogosultságát az általa futtatott alkalmazásokkal megvalósított szolgáltatás adja - az eszetlen önvédelem után maradó állapottal senki sincs igazán kisegítve...
------------------------
{0} ok boto
boto ?

"Az OOMkilller meg eleve baromság _szerintem_, mivel az OS létjogosultságát az általa futtatott alkalmazásokkal megvalósított szolgáltatás adja - az eszetlen önvédelem után maradó állapottal senki sincs igazán kisegítve..."

+1

"Ez Linuxizmus."
mire gondolsz?
Freebsd -n van problémám vele.

"Az ARC A betűje az "adaptive" kifejezést takarja, és olyan rendszereken, amire nem gumipókkal erőltették rá a ZFS-t, ez OOTB menni is szokott szépen."

Igen, de pl. solaris -on meg nincs geli, így maradok a freebsd -nél. :)
Egyébként elvileg freebsd -re se gumipókkal van felkötözve a zfs.

Ez esetben felszínes voltam amellett, hogy tájékozatlan is, mert nem esett le, hogy nem Linux, mert/és a FreeBSD-t csak alig ismerem, például annyira sem, hogy tudjam, hogy van OOMkiller-e. :) Sorry. A geli egy jó érv, nem tudok belekötni - egyébként a Solaris tud titkosítani natívan ZFS-en belül pár éve már. Az OpenZFS sajnos tény, hogy nem.
------------------------
{0} ok boto
boto ?

:)

sajnos a solaris féle natív zfs titkosítás szerintem nem olyan minőségű titkostás, mint a geli.
geli eseten az egesz disk titkositasra kerul transparensen a zfs alatt, mig solaris zfs encrypt eseten csak a zpool es/vagy a zfs datasetek kerulnek titkositasra.
ráadásul gelivel meg tudom csinálni a kéttényezős titkosítást (pendrive+jelszavak), és anélkül nem is bootol a gép.
azt eleve nem is tudom, hogy titkositott zfs-rol tud-e egyaltaln a solaris bootolni, de nem is lenyeg, mert a geli-t jobbnak tartom, valamint a geli boot pendrive+jeszavak jellegű kéttényezős titkosítást is.
aes-ni képes cpu -n még szinte mérhető overheadje sincs egy aes256-xts módú titkosításnak.

Csekély ár mindezért egy !ARC, amit feszt' tutujgatni kell ;D (To each one his own - én például egy Atom N270-en Gentoo-zok helyben fordított csomagokkal... mindenkinek más felirat virít a kedvenc sajtreszelőjén, amivel kötetlen felhasználású pillanataiban létesít légyottot.)
------------------------
{0} ok boto
boto ?

Sosem értettem ezeket a titkosításokat. Mi értelme az egésznek, ha egyszer a kulcs ott fityeg a gép seggében?

Ha megtörik a gépet, úgy is elérik az adatokat, hiszen valahogy decryptelni kell az adatokat, hogy használni tudd. Ha fizikailag hozzáférnek a géphez, elvihetik a pendrivet is. Még annyira sincs rögzítve, mint egy zárható HDD fiók, ha meg belülre rakod, szintén semmi értelme.

Maximum akkor, ha kizárólag boot idejére rakod be a pendrivet, de az meg roppant mód megnehezíti a távmenedzsmentet.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Csak a boot idejere van bent a pendrive. Egyébként ha el is lopnák a pendrive-ot, akkor a kulcsokhoz igaz, hozzáférnek, de akkor is kell a lemezenkénti jelszó, tehát magával a pendriveval nem érnek semmit.
A gép nincs az inernetre kötve, kizárólag vlan -ozva ahova kell. Kicsi az esély, hogy a hálózat felől megtörik.

Ezeknek a titkosításoknak az az értelme, hogy ha betörnek és elviszik a gépet, akkor sem fognak hozzáférni a bizalmas üzleti adatokhoz.

A távmenedzsmentet azért nem nehezíti meg a bott idejére berakott pendrive, mert nem kell újraindítgatni a storage gépet, másrészt a management hálón ssh -n eléred, sőt ilom/ipmi meg mindne működik.
Igen, ha rebootolni kell, akkor fizikailag oda kell menni valakinek a pendrive-val, a jelszavakat meg az SSL-es ipmi konzolon is be lehet már írni.

Ennyit fel kell vállalni, viszont kétévente agy egy ilyen alkalom, kb.

> good luck git checking out egy eddig csak Linuxon fejlesztett projektet

ha egy projektben olyan fejlesztők dolgoznak, ahol mondjuk a header.jpg és header.JPG különböző fájlok, akkor ahhoz a projekthez nem szabad csatlakozni, mert később is te fogsz szívni a többiek hülyeségei miatt

Sokszor meg nagyobb cegeknel is olyan kulonbozo kodminosegbe futni, hogy el sem hinned. Egyik codebase-t egy lelkiismeretes csapat irta kemeny szakmai ellenorzesekkel, masikat meg elvallaltak kulsosok gyorsan, behazudott szakmai tapasztalattal, de mas nem vallalta arra a hataridore, es az allandosok kesobb szembesultek a kodminoseggel, mikor az mar release-elve volt, nem is szoltak senkinek. Allandos tech arcbol egy latta release elott, az is varta a meeting veget, mert 3 masik dolgot kellett volna aznapra befejeznie. Total mindennapi eset.

Amugy en a rossz kodminosegen mar nem akadok fent. Az azzal jaro inkonzisztens adatbazis: na az tud a sirba vinni, foleg ha jo nagy es a "joisten tartja ossze". Az a ritkabb, hogy talalok valami unique indexpart hatalmas N-M kapcsolat tablakon.

Na, /mr/linux. Tenyleg, akadjunk mar le ezekrol a dolgokrol. Addig vicces, amig kontextusa van, de tok ertelmetlen helyzetben elorangatni unfair dolog.

Amugy tok igaza van. Attol fuggetlenul, hogy a POSIX-kompatibilis rendszerek kepesek megkulonboztetni a lofaszt a Lofasztol, meg nem szerencses, ha ket fajl neveben a legnagyobb kulonbseg a kis/nagy betuk mas allasa. Gelei erre vilagitott ra, es megmondom oszinten, azon ritka alkalmak egyike van, amikor egyetertek vele.
--
Blog | @hron84
Üzemeltető macik

> Na, /mr/linux.
A különbség az, hogy én nem arra verem itt, hogy milyen ótvar a Windows és minden lehetséges alkalmat megfogok arra, hogy a linuxos fasz design döntéseket védjem kontextustól függetlenül, offolva, körmömszakadtomig stb. Sőt. Vannak MS szoftverek, ami kifejezetten tetszik és figyelek (pl. TypeScript).

Egy ideig nem tartottam szánalmasnak hogy egymást szopkodják itt fel _MINDEN_ topikban ahol előjön bármi (lásd itt is, HFS-től kezdve az ext-ig mindent leszólt az illető, de mivel az NTFS-t is, ezért jön is a védőangyalsereg), de most már kicsit igen...

Legutóbbis tök jó beszélgetés volt Pascalról, Crossplatform compilerről, IDE-kről, stb., amikor valaki véletlenül megjegyezte, hogy a VisualStudiónál látott már jobbat, RÖGTÖN ott termett az egyik, hogy nahátdeazmármikoriverziósatöbbi.. Minek? Crossplatform cuccokról volt szó, VS
kanyarban sincs...

Azt nem értem, hogy egy nyíltan, már több, mint tíz éve FOSS/Linux/Unix irányultságú oldalon miért jó ez. Nincsen valami jó kis windows/office/.net/egyé~1 oldal ahol ezt lehetne...?

A szokásos pattern.
- Valaki megjegyez egy tényt
- Jöttök, hogy de különbenis, hogy de az úgy jó és ahogy emberek csinálják, az a nemjó, stb. stb.

A mostani kifejezetten izgi, hiszen te magad le is írtad, hogy a case-sensitive fájlrendszereknek nincs létjogosultsága. Gratulálok.

Még poliverzum sem volt ennyire irritáló, de úgy látom muszáj leszek bővítenem a hupper filterem. (done)

howtoRenameFilenameToCaseInsensitiveMadness.gif

Ami igy nez ki:

HOWTO.RENAME.FILENAME.TO.CASE.INSENSITIVE.MADNESS.LNK
HOWTOR~1.GIF

Persze hallgatom am az eszerveket. Csak igy tovabb.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

mint ahogy mindig létezik is.

a kedves MS Hungary figyelmét igazán felkelthetné, hogy a "khiraly" es "kmARC" néven futó jóképességűek tudásuk mégoly' végtelen eszköztárát felsorakoztatva is sikeresen összekeverték a FAT és az NTFS filerendszereket (hja, bárkivel megesik ebben a naonbonycsi szakmában!), lévén előzőnél van kötelezően a ~1 tipusú LFN enhancement/hack, NTFS-nél nem kötelező, és ki is kapcsolható.

https://technet.microsoft.com/en-us/library/cc976808.aspx - alul

szorgalmi feladat a fenti szakmai csimborasszók számára ezt a 30 éves backward-compatibilty scenariot összevetni azzal, hogy a linux és az fsck elpánikol/kilép, ha egy ~3-10 évvel korábban készült ext2-t (2!) kell mountolnia, "unsupported features" címszóval XD

> is sikeresen összekeverték a FAT és az NTFS filerendszereket

Nem kevertem semmit ossze:
http://hup.hu/szavazasok/20151213/hovd_2015_kedvenc_fajlrendszer#commen…

Egyebkent en nem szemelyeskedtem, igy elvarom, hogy te se tedd.
En itt veled az okfejtest befejeztem, abban hiszel, amiben akarsz.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Meg olyat is lattam, hogy www.weboldal.com/util es www.weboldal.com/Util kulon volt: util-t kontrolelrkent ertelmezte az index.php, Util/ pedig egy mappa volt. Nem szep, de ha Windows-on egy ilyen repot kell kicheckoutolni, van szopas. Es ugy tudom branch neveknel se szereti a git, ha a goodfeature es a goodFeature kulon branch es nem Linux az aki masodjara checkoutolja ki.

Es nem az a bajom, hogy az NTFS defaultkent nem case-sensitive. A HFS+ is az. Csak ez utobbit le tudod formazni case-sensitive-kent is. Az NTFS-t meg nem. (A HFS+-on se tetszik, hogy ujra kell formazni hozza)

"Meg olyat is lattam, hogy www.weboldal.com/util es www.weboldal.com/Util kulon volt: util-t kontrolelrkent ertelmezte az index.php, Util/ pedig egy mappa volt. Nem szep, de ha Windows-on egy ilyen repot kell kicheckoutolni, van szopas."

Vagy symlink van a repóban. Vagy egy file, a nevében kettősponttal. Vagy kérdőjellel.

"Es ugy tudom branch neveknel se szereti a git, ha a goodfeature es a goodFeature kulon branch es nem Linux az aki masodjara checkoutolja ki."

Macerásan bár, de case insensitive filerendszeren is megoldható, csak gyakran kell 

git pack-refs --all

-ozni.

"Csak ez utobbit le tudod formazni case-sensitive-kent is. Az NTFS-t meg nem."

Az NTFS mindig case sensitive a POSIX namespace-ben, akárhogyan formázod.
Amivel itt összekevered az a Win32 namespace, amely nem case sensitive.
https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs…

Üdv,
Marci

Én nem mernék olyat kijelenteni, hogy az egész interneten csak az MS használ valamit. :D

Egy valid URL-ben lehet zárójel. Zárójel nélkül is van élet, igazad van, de ez a URL érvényes. Mintha azt mondanád, hogy ne használjunk ~ jelet egy URL-ben. Nem túl gyakori, jól meglennénk nélküle, de miért ne lehetne használni?

Felreertettel. Nem azt mondtam, hogy ne hasznaljuk (pont a Wikipedia jart egyebkent a fejemben, amikor irtam), van, ahol van letjogosultsaga a dolgoknak. Viszont, a weben vannak irott es iratlan szabvanyok, amiket mindenki betart. Az egyik ilyen, hogy parametereket parameterkent adunk at, es nem az URL-be eroltetjuk be, ha nem muszaj. Jo, hogy az MSDN-nel mukodnek a dolgok a zarojeles cucc nelkul is, de ez nem azert van igy, mert a web igy mukodik, hanem azert, mert az MSDN programozoi valahogy lekezeltek ezt a helyzetet is. De ez nem egy generikus dolog.
--
Blog | @hron84
Üzemeltető macik

"Viszont, a weben vannak irott es iratlan szabvanyok, amiket mindenki betart."
Hihetetlen naiv vagy. Még az írott szabványokat sem tartják be mondjuk maguk a böngészőkészítők sem. Nagy cégek vannak, amelyek a szabványokat írják bizottságokon keresztül, és nagy nyílt webnek látszik minden, miközben arról szól az egész, hogy a Google-nek vagy a Microsoftnak, vagy az Apple-nek nagyobb a lobbiereje.

Az, hogy az MSDN valid URL-t a "web írott ér íratlan szabványait" lefosó Drupal 5 nem tudja parzolni, az nem az MS problémája.

Értem én, hogy MS hater vagy, de itt nem az MS a hülye. Hanem a szabvány a hülye, hogy megengedi a zárójelet az URL-ben. Eleve nincs a pathnak semmilyen szemantikája, és a zárójelnek sem. Lehet kopogtatni a szabványosítás mögött álló cégeknél, hogy az URL szabvány szar. Ki fognak röhögni.

A URL-kezelés _írott_ _szabványában_ engedélyezett a zárójelek használata. Ha valaki (böngésző, fórummotor, akármi) nem tud mit kezdeni a zárójellel egy URL-ben, akkor az nem követi a URL-ekre vonatkozó szabványt.

> Az egyik ilyen, hogy parametereket parameterkent adunk at, es nem az URL-be eroltetjuk be, ha nem muszaj

Aztán mi a baj a "http://hup.hu/comment/reply/144507/1941587" jellegű URL-ekkel?

> átalakul

off: Pedig nem kéne.

"In general URIs as defined by RFC 3986 (see Section 2: Characters) may contain any of the following characters: ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-._~:/?#[]@!$&'()*+,;=. Any other character needs to be encoded with the percent-encoding."

/off

Nem nagyon érdekel a probléma, csak jeleztem, hogy műszaki embernek a) nem kéne problémát jelentsen b) nálam nem jelentkezik c) Firefoxszal átalakul (HUP-tól függetlenül, kijelölöm, beillesztem mondjuk egy gedit-be, ott is átalakul) d) a leszarom kategória probléma, kár is jelezni

--
trey @ gépház

trey mar joideje mindent a leszarom kategoriaba sorol, ami a hup technikai szinvonalat erinti.

Neha meg esetleg magyaraz a visszajelzes menupontra (gondolom zavarja, hogy nyilvanosan nyoma marad, hogy szar az oldal), de igazabol fel nem fogom, hogy mi nem egyertelmu visszajelzes, ha valamit tobben szova tesznek.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Arrol en nem tudok nyilatkozni, hogy masok mit csinalnak, magam reszerol meg szerintem csupan egy levelet irtam neked egy regisztracio miatt.

Viszont, ha sorozatban az jon vissza, hogy szarod le, nem erdekel, ez a hup, mer kell itt ugy mukodnie valaminek, mint egy normalis rendszer, hisz teljesen normalis az, hogy a & < > jelekhez kezzel irjuk be, hogy &amp; &lt; &gt; egy code tag kozott, akkor ne csodalkozz, hogy egy ido utan megunjak az emberek.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Ne haragudj, de olyan igénytelen emberek közt, akiknek arra sincs igényük, hogy ékezettel írjanak, hogy a mondat elejét nagybetűvel kezdjék, hogy a saját írásaira minimális formázást tegyenek, hogy a minimális stilisztikai jegyeket felvonultassanak, hogy meg tudják különböztetni a fórumot a blogtól, azt gondolná az ember, hogy tök mindegy.

Viszont ha így viselkednek az emberek, akkor ne csodálkozz, hogy egy idő után megunom.

A többit meg itt szedtem össze.

Ez az egyik. Azzal is tele a faszom, hogy te állandóan offtopikolsz, amikor éppen okádhatnékod van.

(Technikai funfact / háttérinfó): az oldal rendszergazdájának egy hónapja írtam levelet bizonyos problémákkal kapcsolatban. Azóta válasz sem érkezett. Elég nehéz így valamit is dolgozni.)

--
trey @ gépház

"csak jeleztem, hogy műszaki embernek a) nem kéne problémát jelentsen"

Csak jelzem, hogy a szamitogepeket azert talaltak fel, hogy az ember dolgat egyszerusitse, nem azert, hogy utana kezzel csinalja az ember azt, amit egy gep is meg tud csinalni.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Erőltetett példa (ezért is van ott a smiley), hogy lásd teljesen eltér a kinézet és mást is jelent a kettő.

Mondok egy nem annyira erőltetett példát.
Valaki fényképeket készít állatokról, amilyen állat van a képen olyan fájlnevet ad neki. Ha több állat is van a képen, akkor mindegyiket nagy kezdőbetűvel egymás után írja, a nagyobb (fontosabb, ...) állatot előre írva.
Pl. Kutya.jpg, Macska.jpg, LóMacska.jpg, Lódarázs.jpg, ...
Sajnos a legújabb képét, amin egy Ló és egy Darázs van, azt már nem tudja elmenteni a fenti nevezéktan alapján.

Nyilván ez is egy kicsit erőltetett, mint ahogy az mÉrték.txt és mérték.txt is az lenne, de attól ezek még lehetnek valós igények.

Fent már kifejtettem, hogy miért nincs értelme annak, ha meg akarna védeni minket az elgépeléstől. Ezen kívül mi az amiben jobb a case insensitive fájlrendszer?
Abban ugye biztosan rosszabb, hogy nem tud annyi mindent eltárolni.

erre terjedt el a fajlok ilyen irasmodja:
Star.Wars.the.Force.Awakens.mkv

Meg az ilyen is:
2015.penzugyi.beszamolo.doc.doc

Szoftverprojekteknel is terjed ez a pontozas, mint a futotuz:
server/components/database/neo4j.db.access.kit

Ez az egesz pont ahhoz hasonlit, mint a szimbolikus linkek windows alatt.
Tudja, van, de a kutya se hasznalja...

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Megjegyzem, egy átlag user alapból minden további nélkül leírna egy sima szóközt, csak a spacefóbok kezdenek el pontozni, kötőjelezni, aláhúzást használni, stb. Mert valamikor a kőkorszakban valaki kitalálta, hogy ez a sátán műve és jajúristen, hogy képzeli bárki is.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

+1
évek óta túlhaladtuk azt, hogy nem lehet szóköz filenévben.
mondjuk még nekem is arra áll a kezem, hogy szóköz helyett aláhúzást rakok, de igazából az elmúlt kb. 10 évben nem volt problémám szóközös filenevekkel sem, pedig többféle rendszert is használok, kezelek.

Ja, es tegyuk rogton hozza, hogy a space-fobia azert alakult ki, mert Linuxon kb. semmi nem tudja ertelmesen elkezelni, hogy space is lehet fajlnevben. Epp aktualisan szopok azzal, hogy backupbol kell egy space-t tartalmazo mappat helyreallitanom, es a parancsba negyvenketezer escapet kell tenni, hogy valahogy atvigye a nyamvadt szokozt. Mert egyszeruen ez egy impossible scenario, hogy nekem szokozos mappam van.

Mondom mindezt Linux fanboykent.
--
Blog | @hron84
Üzemeltető macik

'alma\ körte'
és akkor még az ssh túloldalán is jó lesz. Ez akkor is csak 3 escape, ha az igazából kettő szintaktikai elemeit külön számítjuk :-))) De ha valami általam értelmezhetetlen macera miatt nem OK, akkor \\.
Amúgy csak érdeklődöm, h a command.com / izé cmd.exe nem pont ugyanígy buta? Csak ott még 'ez\ se\ lehet', mert "ezt kell írni" - már ha nagyon régi és nagyon halovány emlékeim jók.
Mindazonáltal, ha van egy eszköz: nevezetesen a shell, aminél deklaráltan szeparátor a szóköz, akkor miért csodálkozik valaki, hogy ha szóközt ír, az szeparál? Állítsd át az IFS változót, és akkor majd nem fog szeparálni!

"Mindazonáltal, ha van egy eszköz: nevezetesen a shell, aminél deklaráltan szeparátor a szóköz, akkor miért csodálkozik valaki, hogy ha szóközt ír, az szeparál? Állítsd át az IFS változót, és akkor majd nem fog szeparálni!"

Plusz egy. Ha mar egyszer ez a default, ne akarjuk megeroszakolni, mert ugy kenyelmesebb. En nem latom, miert olyan bonyolult szokoz helyett alahuzast vagy pontot rakni a filenevbe.

--
http://www.micros~1
Rekurzió: lásd rekurzió.

Akkor talán nem hülyeségeket kellene ráerőszakolni az userekre, hanem megjavítani azt, ami rossz. Jelen esetben a Linuxos(/BSD-s/stb.) CLI toolokat. GUI-s környezetben valahogy mégis sikerült megoldani mindhárom vezető oprendszernek.

Nehogy már az elbaszott toolok írják a felhasználói igényeket, mert akkor még mindig a 8.3-nál tartanánk.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

A CLI nem rossz, hanem más módon korlátos, mint a GUI(*). Azért várnék ötleteket arra, hogy mi lenne az ideális javítás a CLI-ben arra a problémára, hogy úgy tervezték, hogy szóközökkel lehessen elválasztani a parancssor elemeit, ellenben a rendszer némi szabadságot biztosít, így ugyanazok a szóközök a fájlnévben is megengedettek - és az ellentmondás kiküszöbölése érdekében 3 különböző (egymással majdnem tesztőlegesen keverhető) módon lehet a szóköz jelentését eltakarni a tool elől.

$ echo ez\ \ e'gy k'ib"a* ronda  so"r.amiben.a.paraméter_egyetlen_szó
ez  egy kiba* ronda  sor.amiben.a.paraméter_egyetlen_szó
$

(*) arra gondolok, hogy pl. a parancssor használata esetén nehézkes (de nem lehetetlen) szóközt rakni fájlnévbe, ellenben a GUI-n (tudtommal) nem nehézkes, hanem lehetetlen tabulátort tenni ugyanabba a fájlnévbe. Pedig az is lehet valakinek agybaja.

Eleve nem értem, minek ennyi escapelés. Ugyan Windowson egyszerűbb, mert tiltott a ", de sokkal egyszerűbb, hogy nem kell minden ákom-bákom elé \-t tenni.

(Mondjuk amitől egyszer igazán agyfaszt kaptam, az az xcode, simán enged enter jelet egy fájlnévben, mert valami textboxot úgy állítottak be, hogy elfogadja az új sor jelet.)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Szerintem ezt benézted. Nem arra volt példa, hogy így *kell*, hanem arra, hogy ha a feladat megkívánja, akár így is *lehet*. Ha nagyon egyszerű a helyzet, akkor 'simán aposztrófok közé' teszek mindent, és készen vagyunk. De ekkor nem lesz pl. (változó)helyettesítés. Vagy ha csak egyetllen spéci karaktert kell takarnom, akkor spórolósabbb a \ez forma. Ha. Ha. Ha. Csupa feltétel, amiből tudsz választani.

(Amúgy meg újfent felteszem a kérdést - neked az a természetes, hogy a fájl nevében szóköz van. Másnak meg az a mániája, hgy a verseit úgy tárolja, hogy a fájl neve az a vers első pár sora - márpedig oda ENTER *kell*. Ezt a *X világ és a CLI lehetővé teszi. És másutt mi a helyzet?)

*Én* tudom használni, noha én nem szoktam. Igaz, ha rajtam múlik én a szóközt és tabulátort se, mert kiváltom a korábban más áltam már emlegetett ponttal és aláhúzással (máskor meg kötőjellel). De pl az itt sokszor emlegetett bash "taboláskor" automatikusan ilyen\ formában\ egészíti\ ki\ a\ fájlneveket. Hol itt a probléma? Kevesen vagyunk, akik ki szoktuk írni.

Egy kevesbe eroltetett pelda:

Multkoriban irtam egy NoSQL adatbazis <-> fajlrendszer gatewayt.
Azaz barmelyik adatot ki lehet venni az adatbazisbol fajlkent, es vissza is lehet tenni.
Ahhoz, hogy ne legyen informaciovesztes, es a fajl nevek ne id-k legyenek, igy a title-t kapta meg. Viszont itt illik megkulonboztetni a kis es nagybetuket.

Van egy masik workaroundom is:
Mivel bongeszobol konyvtarat rekurzivan nem lehet feltolteni*, igy
a backup script automatan letrehoz egy symlinks/ konyvtarat es minden fajlrol csinal oda egy symlinket konyvtarrendszerrel egyutt.
Ezt fel lehet tolteni, es vissza lehet pakolgatni a fajlokat az eredeti helyere (teljesen automatan).

Linux/MacOSX alatt megy szepen az egesz. 600GB/1.1M fajllal probaltam.
Windows ala 5letem sincs, hogy mit csinaljak. Egyreszt ott van a kisbetu-nagybetu mizeria. Raadasul Van\\olyan,fajlom:amit| egyszeruen>nem.eszik.meg.a.windows*,es.nem.ertem.miert?.txt :)

Masreszt a szimbolikus linkek se igazan mennek win alatt.
Letrehozhatnam azt a binaris .lnk formedvenyt, de feltolteni se a firefox, se a Chrome nem tudja (marmint a .lnk fajlt tolti fel, es nem amire mutat).

Talan mklink -kel kellene tenni meg egy probat.
Szerencsere nem husbavago kerdes a Windows support, mint ahogy rengeteg trendy projektnel elobb kell normalis MacOSX support, mint windows.
De azert megiscsak idegesit...

*: Elvileg Chrome tudja, de 100-nal nekem kifagyogatott, es itt 10e+ fajlrol van szo

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Fasz, mert több évtizedes megszokás azt diktálja. Ha sosem jelentett volna ez gondot, valószínűleg senki nem jönne elő ilyen érvekkel, mert teljesen természetes lenne, hogy ahogy az írott nyelvben is jelentést megkülönböztető szerepe van a nagybetűnek, úgy a fájlnevekben is megkülönböztető szerepű.
Mondjuk érdekes módon azok akik ezen lovagolnak, az utf-8 és utf-16 kódolású fájlnevek ellen nem szoktak lázadozni (mert az a szívüknek kedves rendszer nagyra értékelt fícsörje volt sokáig? :) ). Pedig hasonló cipő, ha úgy vesszük semmi szükség rá, hiszen ASCII karakterekkel is meg lehet különböztetni végtelen sok fájlt...

est OS X -en sem tudnad eljatsszani!

hint: oda tudod rakni enkepem_szek.JPG -kent, peldaul.

by design hulyeseg, amit csinalsz, hogy ugyan azon a neven van .JPG es .jpg fileod, ezt ha modnjuk valakinek ki kell masolnod pendrivera, es mondjuk mas rendsezren megnezni, akadhatnak problemaid...
a case-sensitive filerendszer is by design hulyeseg, ha jobban belegondolunk.

"mondj egy konkrét use case-t, miért jó, ha a header.jpg és header.JPG nem ugyanaz?"

Ide válaszolok, de a szálba szinte bárhova beleillik.

Az a mondás, hogy azért jó, ha nincs megkülönböztetve a kis és nagy betű, mert akkor a meg van védve a felhasználó, hogy véletlenül ugyanazt (más-más verzióban) több állományban tárolja.
Sajnos ez nem menti meg. Ugyanúgy elírhatja a header.jpg-t heder.jpg -re, vagy haeder.jpg-re. Ezektől is mentsük meg?
Dolgoznál olyan projekten, ahol van header.jpg, haeder.jpg vagy fejléc.jpg?

Akkor az ékezetektől is mentsük meg, mert különben lesz mérték.txt-je, mertek.txt-je, mindegyikbe ugyanazt akarta rakni, de nem emlékezett, hogy használt ékezetet vagy nem (Ezeket viszont engedjük? merték.txt és mértek.txt).

Mentsük meg az elgépelésektől, lásd fenn. Ami egy-két betűben tér el, azt ne engedjük!

Mentsük meg a hasonló jelentésű szavaktól, iskola.txt, suli.txt vagy tíz.txt, 10.txt.

Mentsük meg ha ugyanazt jelenti, de más nyelven, tíz.txt, ten.txt.

Mentsük meg a hasonló kinézetű szavaktól, 10.txt lO.txt (vannak karakterkészletek, ahol ezek megkülönbözhetetlenek.)

Szerintem ez nonszensz. A fájlrendszernek az a dolga, hogy tárolja el az adatokat, nem az, hogy megvédjen a felhasználói névadási problémáktól.

Esetleg rakják be ezt a tudást az OS mentés dialógusába, de ott is úgy, hogy lehessen úgy dönteni, hogy de én mégis mind a két (több) verziót tárolni akarom.

Mert a kis-nagybetűk megkülönböztetése a téma. Csak az. Nem az, hogy a 10.txt-t meg a tíz.txt-t és a tiz.txt-t is egy fájlnak vegyük-e vagy sem.

Bár részben rokon a szalmabáb érveléssel is, mikor az eredeti állítás helyett egy másikról kezdesz el vitatkozni.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Azt hiszem nem értetted meg a lényegét!

Eddig egy érvet hallottam a case insensitive mellett, azt hogy ez megvédi a felhasználót, hogy ugyanazt véletlenül két (több) fájlban tárolja.
Ezt cáfoltam, ez nem védi meg.

Ha a cáfolatom nem tetszik vagy tudsz más előnyt mondani mellette, akkor tessék!

Még ez tűnik eddig a legkevésbé erőltetettnek. De vajon YouTube esetén a videó ID a GET-ben megfeleltethető a videó valódi fájlnevének? Én nem mernék rá fogadni.

Ahol annyi fájl van egy mappában, hogy ezzel kell takarékoskodni, szerintem az az architektúra nincs túl jól kitalálva. :)

Miért kéne minden fileművelet előtt ezt megtenni? Csak akkor kell, amikor egy filenév -> file objektum/handle mappinget csinálsz. Ez pedig egyszer történik meg. Amikor meg UI-s file chooser van, akkor egyszer sem. Csak a text alapú interfészek esetén fontos a file neve, hiszen ott kell egyedül filenév -> file objektum leképezést csinálni. Utána viszont minden más megnyitott file handle-lel megy.
Javaban is File-okat kezelsz, magas szintű absztrakt objektumokat, nem filenevekkel végzed a műveleteket, hanem File objektumokkal. C-ben meg FILE handle-vel.

"Miért kéne minden fileművelet előtt ezt megtenni? Csak akkor kell, amikor egy filenév -> file objektum/handle mappinget csinálsz."

Igen, akkor és ott kell transzformálni a paramétereket és az éppen elég is...

...ha már ennyire tervezett a case insensitive, akkor legalább találtak volna ki rá egy karakterkódolási (belső) szabványt, de nem, ASCII, ISO-8859-* vagy UTF-* a karakterkódolás a fájlnévben is, ami perszehogy case sensitive és megy a trükközés minden interfészen és/vagy programban, hogy mégiscsak transzparensen case insensitive legyen, de nem transzparens. Architekturálisan jól van tervezve, persze... :/

--
https://portal.gacivs.info

Miért, te a GET-et transzformáció nélkül felhasználod fájlrendszerműveletekben?

> Architekturálisan jól van tervezve, persze... :/

Olvasd el még egyszer a hozzászólásom idevonatkozó részét, rá fogsz jönni, hogy ebben a subthreadben nem a fájlrendszer működéséről beszéltem, hanem egy bizonyos fajta adattárolásról.

"Miért, te a GET-et transzformáció nélkül felhasználod fájlrendszerműveletekben?"

Igen, legtöbbször transzformáció nélkül felhasználom. A validáció nem transzformáció.

"Olvasd el még egyszer a hozzászólásom idevonatkozó részét, rá fogsz jönni, hogy ebben a subthreadben nem a fájlrendszer működéséről beszéltem, hanem egy bizonyos fajta adattárolásról."

Bizonyos fajta adat fájlrendszerben való tárolásáról beszéltél...

A Microsoft operációs rendszereinél mindig elég erős volt a visszafelé kompatibilitás.
Ha Te lettél volna a DOS, majd Windows divízió feje hosszú időn át, mondjuk az MS-DOS 3.25-től kezdve (ami case insensitive), mely OS verzióval váltottál volna át a case sensitive működésre? Egyáltalán meglépted volna, tudva, hogy ezzel erősen veszélyezteted a visszafelé kompatibilitást?

Üdv,
Marci

Mintha eltértünk volna a tárgytól...

"Javanal mikor lesz a visszafelé nem kompatibilitás eldobása?"

Miből gondolod, hogy a Java esetén van visszafelé kompatibilitás? :)

Azt mondanám, hogy nagyrészt visszafelé kompatibilis, viszont sok dolgot kivezettek vagy átalakítottak, ami okozott és még okoz bőven problémákat.

"Mondjuk a java.net.URL kivezetése és hasonlók."

A funkcióját betölti, miért kellene kivezetni?

"Mert van helyette jobb, az URI class."

Más a funkcionalitása a kettőnek (lásd URL, URN és URI).

"Ugyanúgy, miért kéne kivezetni a case-insensitive filerendszert, a funkcióját betölti."

Ahogy már írtam volt: egy case sensitive fájlrendszeren könnyebben meg lehet oldani a case insensitive működésmódot, mint fordítva.

Egyébként szinte mindent case sensitive használsz: szinte biztos, hogy case sensitive nyelven programozol, szinte biztos, hogy case sensitive módon használod az adatbázisokat és szinte biztos, hogy case sensitive módon használod a szövegek nagy részét, külön jelölnöd kell minden nyelven, hogy case insensitive akarsz keresni vagy összehasonlítani...

Amikor case insensitive DOS volt, meg case insensitive BASIC, akkor volt értelme a case insensitive fájlrendszernek... és el kellene dönteni, hogy kompatibilitási okokból van még meg vagy haszna is van az egyre inkább case sensitive környezetben.

--
https://portal.gacivs.info

Senki nem kardoskodik a case insensitive mellett ab ovo. Hanem amellett, hogy meg kéne érteni, hogy a backward compatibility miatt sok minden legacy dolog létezik, amivel együtt kell élni. Az egész szál erről szól, sokan nem képesek ezt megérteni, hogy van, amikor ez fontosabb.

Nem kell együtt élni a kompatibilitással, csak okosan és tervezetten kell átterelni a népet az új interfészekre, különben csak akkumuláljuk a szopást és taszigáljuk magunk előtt a szargalacsint.

"Annyira így van, hogy még _Franko_ sem lépte volna meg a váltást az elmúlt 26 évben, ha rajta múlt volna..."

Arról az oprendszerről beszélünk ugye, amelyik 26 éve is már virtuálizálta a DOS-t (NTVDM), ugye? Mikor máskor lett volna erre jó időpont?

--
https://portal.gacivs.info

Bármilyen olyan script, ami feltételezi, hogy a filenév case insensitive.

Csak egy kérdés, mondjuk még a DOS/Windows 9x korszakból: mi az autoexec.bat rendes neve? AUTOEXEC.BAT? Rengetegen így hivatkoznak rá. Vagy autoexec.bat? Rengetegen meg így hivatkoznak rá. Esetleg autoexec.BAT? Ez mind-mind ennek a filenak a neve.

Hogy másképp mondjam: ennek a file-nak rengeteg neve van, így egy script bármelyiket használja, helyesen fog futni, a rendszer sokkal kevésbé érzékeny az input hibáira (pl. ha véletlenül AutoExec.BAT-ot írsz, akkor is okés a dolog).
Míg case sensitive esetben a file-nak pontosan egy neve van, és sokkal érzékenyebb az elgépelésekre.
Vagy másként: ha egy case insensitive rendszerről másolsz át egy FILENAME.EXT névvel is hívható filet, akkor milyen néven jön létre a case sensitive rendszeren? FILENAME.EXT vagy filename.ext vagy FileName.ext stb? Mi lesz a neve ennek a file-nak, melyik a sok közül?

Még mindig a DOS/Win9x rendszerekkel akarnak kompatibilisek maradni?
Értem mit akarsz írni, de egy fájlnak akkor is csak egy neve van, amit meg is lehet nézni, hogy mi.
Az, hogy többféle formában is elfogadja a "hibás" inputot az egyrészről valóban megvéd egy-két elgépeléstől, de mint korábban írtam, nem véd meg nagyon sok mindentől.
Másrészt biztonsági kockázat is, ha case sensitive fájl rendszeren (pl. felcsatoljuk) futtatjuk a programunkat.
Win 8.1-en pl., ha van egy AUTOEXEC.BAT és egy autoexec.bat fájlom ugyanabban a könyvtárban, akkor AUTOEXEC.BAT-ra is az autoexec.bat-ot futtatja.

Nem, enpassant nem tudja elképzelni azt, hogy bizony van olyan, hogy egy case insensitive filerendszerről rendszerszinten migrálunk case sensitive filerendszerre, például amikor egy Windows 98-ról Windows XP-re migrálnak a felhasználók.
A Microsoft ügyelt arra, hogy ami Windows 98 alatt nem volt probléma, az Windows XP alatt se legyen probléma. És ennek része az, hogy a Win32 API an NT-ben is case insensitive módon kezeli a fileokat, még akkor is, ha az alatta lévő NTFS filerendszer case sensitive. Tényleg meg kéne érteni, hogy a business világban a zöld mezős "na mostantól minden meglévő dolgot eldobunk, mert friss lett az OS" beruházás nem sok van.
Amikor meg éppen csinálna valami olyat az OS, ami miatt visszafelé nem kompatibilis, akkor is a MS a hülye, nyilván, meg az ügyfél, aki még mindig nem migrált Windows XP-ről vagy esetleg még korábbról. Nyilván. Mindig más a hülye.

Nem kívánok belefolyni a vitába (mivel nemigen vagyok ezekben jártas), csak egy elírásra (typo) hívtam fel a figyelmet. Bár már kezdem azt hinni, hogy csak én látom úgy, hogy enpassant mindkétszer (feltételezem, véletlenül) "case sensitive"-et írt ("ha case sensitive-ként használnánk a case sensitive fájlrendszert").

Nem is a Win9x-ről Win XP-re migrálással van a baj, hanem, hogy azóta se lépte meg.
Azt is meg kellene érteni, hogy a business világban, aki nem tud gyorsan változni, az hatalmas verseny hátrányban van. Az, hogy cipelünk magunkkal egy rossz dolgot, az egyre több problémát szül.
Mit lehet tenni?
Azt, amit a programozási nyelveknél is csinálnak, először "deprecated"-re rakni, minden működik ugyanúgy, de warning-ol. Majd egy-két verzióval később kivezetni.

Ez a "ki a hülye" példa az MS és az ügyfél viszonyára utal? Ügyfél szerint az MS, MS szerint pedig az ügyfél? Jól értem? ;)

"Azt is meg kellene érteni, hogy a business világban, aki nem tud gyorsan változni, az hatalmas verseny hátrányban van. Az, hogy cipelünk magunkkal egy rossz dolgot, az egyre több problémát szül. "
Ez az egész IT-re igaz. A UNIX és Windows is 1970-es években kitalált operációs rendszer. Mindkét rendszernek hatalmas hátrányai vannak, kezdve akár a C nyelvű API-val meg még sok minden mással, tele van koncepcionális hibákkal az összes modern UNIX és UNIX-like rendszer, és a Windows is.
Az X86 platform is csomó rossz dolgot cipel maga után már 30 éve.
Nosza, le lehet őket cserélni, csak ne várd, hogy populáris legyen. A MS elkezdett legalább kutatni a témában (Project Singularity és társai), de ekkor is hülyének nézik őket, meg akkor is, amikor objektumorientált shellt csinálnak stb. Így nehéz ám modern dolgokat csinálni, ha akkor is fikázod őket, ha fejlődnek, meg akkor is, amikor nem. Linux világban ilyen a SysV init. Mindenki ezt szereti, ezt akarja vissza a systemdről, az 1970-es évek technológiáját. Gratulálok.

"Ez a "ki a hülye" példa az MS és az ügyfél viszonyára utal? Ügyfél szerint az MS, MS szerint pedig az ügyfél? Jól értem? ;)" A HUP-on mindkettő a hülye.

Igen, az Ő hozzászólására. Ezt írta:
"Arról szól, hogy miért case insensitive módon használunk egy case sensitive filerendszert"

Kiegészítve az idézet:
~"Arról szól, hogy miért case insensitive módon (Windows) használunk egy case sensitive filerendszert (NTFS)"

Tehát arra voltam kíváncsi, hogy mi lenne, ha a Windows case sensitive-en használná a case sensitive fájlendszert (pl. NTFS).

Tehát kb. 26 éve lehetett volna valakinek architekturálisan másképpen döntenie Szerinted, amikor a DOS 4.0 volt a legfrissebb PC-s oprendszer és Linus Torvalds vidáman nyomkodta a Sinclair QL-jét, PC-je még nem lévén.
Ha az illető meg is tette volna, ma lehetne case sensitive Windows-unk. Biztos, hogy aktuális kérdés ez? :D

Üdv,
Marci

"Tehát kb. 26 éve lehetett volna valakinek architekturálisan másképpen döntenie Szerinted."

Baszki, Te kérdezted, hogy mikor lett volna jó... igen, 26 éve kellett volna ezt a döntést meghozni. :)

"Ha az illető meg is tette volna, ma lehetne case sensitive Windows-unk. Biztos, hogy aktuális kérdés ez? :D"

Mivelhogy a környezet egyre inkább case sensitive, és bőven van szopás abból, hogy case sensitive környezetből kell portolni alkalmazásokat case insensitive környezetbe is: igen, aktuális kérdés.

--
https://portal.gacivs.info

Igen, mert a filekezelom ugyis megmutatja a thumbnailt, annak alapjan fogom felismerni. Vagy meta-adatokbol kinyeri a cimet, es azt mutatja alapbol, elrejtve a valodi filenevet.

Igy a filenev tokmindegy, es az ID-ben levo azonosito kezenfekvo.

(En pl pont igy tarolom a youtuberol lementett videoim, mert a file managerem okos, keresni meg meta-adatok alapjan fogom, nem filenev alapjan - ezt pedig a media managerem oldja meg nekem.)

--
|8]

Valóban; annyira, hogy az én időmben még az volt a kódolási konvenció, hogy a fájlkezelést assign( f, 'FILE.TXT' ) formában szokták kezdeni - volt is belőle anyázás, amikor először kellett Jujniksz rendszeren futtani a programot :-).

(Amúgy korábban szintén konvenció volt, hogy a lo.c és a LO.C nem ugyanaz, lévén az utóbbi C++ kódot jelentett. Persze ezzel is lehetett szopni - és anno a g++ eléggé agyament hibaüzenetet adott akkor, ha C-nyelvű fájlt akartál C++-ként fordítani. Pontosabban emlékeim szerint ilyenkor a linker anyázott.)

mert masra hasznalod, es mert jelzel vele valamit?
matekon gyakran hasznalunk harom garnitura abc-t, nagyon jol alkalmas a kulonbozo rendszerekben valo osszetartozo dolgok jelolesere.

saxus peldajara visszaterve: a kep.jpg vs kep.JPG a legrosszabb eshetoseg, az, hogy itt nincs ertelme, semmilyen szinten nem indokolja, hogy mashol se.
egyszeruen, gyakran van, hogy az adat erzekeny a kis es nagybeture. (es soha nincs, amikor nem az)

az egyetlen erv amellett, hogy ne legyen, hogy a windowsban elcseszetten oldottak meg.
es most az egesz unix vilag torje el a 60 eves kompatibilitasat magaval, csak, mert a window nem kepes kezelni valamit, es mi van ha at kell masolnom valamit valakinek, lol?

"mert masra hasznalod, es mert jelzel vele valamit?"

oooo.... atlathato, karbantarthato kod rulz!

"saxus peldajara visszaterve: a kep.jpg vs kep.JPG a legrosszabb eshetoseg, az, hogy itt nincs ertelme, semmilyen szinten nem indokolja, hogy mashol se.
egyszeruen, gyakran van, hogy az adat erzekeny a kis es nagybeture. (es soha nincs, amikor nem az)"

a filenevbe ne kodolj mar adatot. abba a file nevet add meg, a fileban majd tarolod az adatot. ;)

"az egyetlen erv amellett, hogy ne legyen, hogy a windowsban elcseszetten oldottak meg.
es most az egesz unix vilag torje el a 60 eves kompatibilitasat magaval,"
oooo..... OS X is case INsensitive fs-t hasznal (sot, csak azon hajlando mukodni...), megis UNIX. most akkor ez az unix vilag 60 eves kompatibilitasa hogy ertendo? mire gondolsz pontosan?!.... (koltoi kerdes)

Oke, akkor most mindketten lepjetek ki a dobozbol, es kezdjetek el gondolkodni azon, hogy emberek mi alapjan neveznek el fajlokat. Igen, bizony, valamilyen adat alapjan (mit abrazol a kep, milyen szerzodes, kikkel kotott szamla, etc). Es innentol az adat bizony a fajlnev reszet fogja kepezni, es valamilyen szinten helyreallithatonak, vagy legalabbis felismerhetonek kell lennie.

Ugyanis, ha a fajlnev nem tartalmazhatna adatot, akkor a DSC0001.JPG jellegu fajlnevek terjedtek el volna a vilagban, illetve mindegyik fajlformatumnak kotelezo resze lenne egy plaintext metaadat mezo is, amit minden fajlrendszer kulon is indexelne.
--
Blog | @hron84
Üzemeltető macik

https://www.kde.org/announcements/beta1announce.php

így kezdődik:
An integrated Desktop Environment for the Unix Operating System

Persze ez régi, manapság azt írják:
https://www.kde.org/community/whatiskde/

What does KDE produce?

For users on Linux and Unix, KDE offers a full suite of user workspace applications which allow interaction with these operating systems in a modern, graphical user interface.

De egyébként KDE elég sok rendszerre van elméletileg, még Windowsra is (valószínűleg örökké félkészen). Mondjuk én csak Linuxon használom és most hirtelen nem találtam listát a kompatibilis rendszerekről.

"mert masra hasznalod, es mert jelzel vele valamit?"

oooo.... atlathato, karbantarthato kod rulz!

Valaha régen dolgoztam egy projekten, ahol az osztály nevekben a szavak nagy betűvel kezdődtek, a változónevek meg kisbetűvel.

Szóval mondjuk volt class File, és volt File file

Persze ez nem arra példa, hogy két változó csak nagy meg kisbetűben tér el, viszont két szimbólum igen.

És igen, átlátható, karbantartható volt a kód.

Ez nem kivételes dolog, mivel ez egy bevett gyakorlat Java esetén, olyannyira, hogy
a legtöbb Java IDE a nagybetűs osztályhoz változónévnek a kisbetűs verzióját (is) ajánlja fel.
Nem ördögtől való ez.

A case sensitive a liberális megközelítés, a case insensitive pedig a konzervatív.

"Valaha régen dolgoztam egy projekten, ahol az osztály nevekben a szavak nagy betűvel kezdődtek, a változónevek meg kisbetűvel.

Szóval mondjuk volt class File, és volt File file

Persze ez nem arra példa, hogy két változó csak nagy meg kisbetűben tér el, viszont két szimbólum igen.

És igen, átlátható, karbantartható volt a kód."

Ez hol mond ellent nekem?

nem.
fájlrendszer esetén a fájlnév azonos dolgot jelöl: egy bejegyzést a fájlrendszerben.
aminek típusa lehet fájl, directory, link, symlink, stb.stb..

viszont a Class File esetébena File az egy class, mig a File file esetében a file az egy File class tipusu változó.
totál nem analóg a fájlrendszeres bejegyzésekkel, más absztrakció mind a fájlrendszer, mind a class File és a File file is!

"fájlrendszer esetén a fájlnév azonos dolgot jelöl: egy bejegyzést a fájlrendszerben."

Ez csak akkor igaz, ha a fajlrendszerrol, mint technikai elemzes targyarol beszelunk. A civil eletben, marmint, az informatikai laboratoriumon kivul a nev mindig kepviseli magat a tipust is, mert vagy mellette van a megfelelo ikon, vagy az ls mas szinnel/formatumban listazza ki.
--
Blog | @hron84
Üzemeltető macik

azt, hogy a hasznalt filekezelo program milyen ikont rak kulombozo tipusu (kiterjesztes vagy mime adatok alapjan eldontve a tipust) fileok melle, vagy azokat milyen szinnel jeleniti meg, az mar egy magasabb absztrakcio, koze nincs ahhoz, amirol itt beszelgetunk. ezt nem a filerendszer hatarozza meg, ha akarod irhatsz olyan filekezelot is, ami a 3 karakterbol felepulo nevu fileokat zolddel, a 4 karakterebol allo fileneveket kekke, a 10 karakterbol allo fileneveket citromsargaval, sb.stb. jelzi ki. ez kurvara nem a filerendszeren muli9k, ez az adott program sajatossaga, hogy mit mi alapjan, hogyan jelenit meg. es nem, a nev nem kepvisel semmilyen tipust, regrol visszamaradt dolog, hogy a file kiterjesztese jeloli (de ezt sem kotelezoen) a tipust, es sok filekezelo a mai napig ez alapjan hatarozza meg, hogy az adot fajlrendszerbeli bejegyzest neked hogyan, milyen szinnel rajzolja a kepernyore. tovabba figyelembe veszi a file attrobutumait is, nyilvan. ennek koze nincs a fajlrendszerhez, ahhoz meg plane nem, hogy a fajlrendszer case sensitive vagy case insensitive, te totalisan teljesne masrol beszelsz.

"fájlrendszer esetén a fájlnév azonos dolgot jelöl: egy bejegyzést a fájlrendszerben."

Milyen értelemben? Technikailag így van megvalósítva? Mert logikailag teljesen más egy könyvtár, mint egy fájl.

Ezt egyébként analóg elmondhatom egy nyelvnél is. Az azonosító az csak egy nyelvi elem, aminek a típusa lehet Class, változó, ...

a filenevbe ne kodolj mar adatot. abba a file nevet add meg, a fileban majd tarolod az adatot. ;)

mar miert is ne? Pl. a dnscache a rezolver kliensek ip-cim listajat / tartomanyokat filenevekben (nem pedig a file-okban) definialja.

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

Csak hogy tudd: C# az nem Java. Itt nem kötelező a filenévnek a class nevével megegyeznie.
Egy nyelvnek (nyelvnek!) miért kéne tudnia, hogy milyen platformon fogják implementálni? Magának a nyelvnek nem kell tudnia, hogy a fordítási egységek fizikailag a filerendszerben hogyan helyezkednek el, az csak a fordító dolga, hogy az X classt az x.cs, az x.cpp vagy a /com/components/classes/foo/whatever/X fileból húzza be. A fizikai implementáció totálisan lényegtelen.

Az, hogy egyes nyelvek előírják (nem a fordítók, hanem a nyelvek), hogy egy adott nyelvi elemnek mi kell, hogy legyen a megvalósítása, az baj.
A Java esetében is igazából nem nyelvi előírás az, hogy az A.java-ban az A classnak kell lennie, ez a fordítónak az elvárása. Simán csinálhatnál olyan Java fordítót, ami ezt nem várja el. Illetve olyan JVM-et is, ami az xyz.class betöltésénél betölti neked az XyZ classt. Ugyanis nem a file neve a lényeg, hanem a tartalma, és a classfile format le is írja, hogy az adott file melyik classt tartalmazza. A HotSpot default classloader implementációja a ludas itt igazából, amikor az XYZ class betöltésénél az XYZ.class filet keresi, és mást nem.

A kérdés az volt, hogy ha egy cég létrehoz egy állományrendszert amiben nincs megkülönböztetve kis- és nagybetű, mivel feltételezem szerinte fölösleges, akkor ugyanaz a cég miért látja jónak, hogy egy általa tervezett nyelvben viszont legyen megkülönböztetve. Gondolom lehet erre mondani, hogy másik csapat tervezte, készítette, satöbbi, csak érdekes, hogy egyiknél nem látja értelmét, másiknál meg igen.

"Belépés díjtalan, kilépés bizonytalan."
"Vajon mit várok a sorstól, ha hányok az édestől, és izzadok a sóstól."

és ez miért csak az MS-nél probléma? Swift/Objective-C and HFS, anyone? :D

Amúgy meg: mint már sokan leírták, az NTFS case sensitive.
https://support.microsoft.com/en-us/kb/100625
A probléma itt nem az NTFS, hanem a Win32 API vs POSIX API vs NT API. A Win32 (aka good old days of Windows 9x) tényleg case insensitive, azt úgy tervezték. DOS maradék.

nem hinném, hogy csak ott probléma, de most ez a szál erről szól. feltételezem lehet bővíteni. :-)

csak érdekelne, használja valaki ezt a registry-n keresztül beállítható lehetőséget és a case sensitive tulajdonságát az ntfs-nek? lehet tudni miért maradt meg a dos-ból? emlékeim szerint az ntfs az nt-vel jött, amire pont azt mondták, hogy szakít a korábbi dos-ra alapulok nézettel, így akár lehetett volna case sensitive is, ha már kifejlesztették.

egyébiránt nekem semmi problémám nincsen a case insensitive állományrendszerekkel önmagukban, a probléma ott kezdődik, amikor mozogsz egy case sensitive rendszer felé. romvault-ot használok (C#) és amikor megnyitották, kellett gyomlálni benne, hogy a korábbi case insensitive rendszer után menjen egy case sensitive rendszeren a fordítása Mono alatt.

"Belépés díjtalan, kilépés bizonytalan."
"Vajon mit várok a sorstól, ha hányok az édestől, és izzadok a sóstól."

Ha jól értem, akkor a fenti két különböző osztály C# alatt (is).
Tehát pont ugyanazok a kérdések merülnek fel itt is, mint fájlrendszer esetén.
Tehát, ha case insensitive lenne, akkor nem lehetne ilyet csinálni, de akkor ugyanúgy elérhető lenne a Customer osztály customer, cusTomer, CUSTOMER, ... neveken.
A case insensitive pártiaknak ez tetszik, a másik tábornak meg nem ez, ennyi.

Ha jól tudom az a baj, hogy túl sok i betűjük van... :P

The casing of the dotless and dotted I forms differ from other languages. That implies that a case insensitive matching expected by an English person doesn't match the expectations of a Turkish user. The "Turkish I" is often used as an example of the problems with case insensitivity in computing.

Ez csak annyit jelent, hogy a törökben a "i" és a "I" szimbólumok nem egymás kis- és nagybetűi. Az más kérdés, hogy a unicode előtti hőskorban kényszerből nem vezettek be új karaktereket, hanem újrahasználták az ascii "i" és "I" betűket, amiket nem török locale-on egymás kis- és nagybetűiként kezelnek.

Ez egyáltalán nem megoldhatatlan probléma, ezért nem bizonyítja, hogy a case-insensitivity hülyeség.

Ezzel analóg pl. az a probléma, hogy hogyan érdemes letárolni és megjeleníteni emberek neveit.

Igen.

Simán meg tudják manapság a számítógépek különböztetni a kis i, a nagy i, a kis I és nagy I betűket, ha be van állítva egy török locale.

De azt nem tudom, hogy ha a török haverom készít egy fájlt, amiben ő a pont nélküli i-t használja, mondjuk I.txt, és azt ideadja nekem, akkor vajon nálam pl. windows alatt a gép azt összekeveri-e az i.txt-vel (mert nálam a i nagybetűs párja I-nek néz ki).

Szóval nem tudom, hogy amikor én I-t írok, az ugyanaz a betű-e, mint amikor ő ír nagy pötty nélküli I-t.

Ha nem, ha nála más unicode kód tartozik hozzá, akkor nincs keveredés.

Izé...

most komolyan a görög nagy omega betű és az ellenállás mértékegysége (ohm, ami írásban a nagy görög omega betű) különböző unicode kódot kapott?

Ennek vajon mi értelme? És vajon ugyanígy a latin nagy W az más kódot kapott, mint a teljesítmény mértékegysége (Watt, ami írásban a nagy latin W betű)?

Érdekes.

például lehet egy valid ok, hogy egymás mellett szerepeljenek az ABC-ben a görög betűk, meg a fizikai mértékegységek jelei is.
És, ha valaki ki akarja listázni az összes görög betűt (mert, mondjuk egy kattintható szimbólumlistát szeretne) akkor elég egy for ciklus, ugyanígy, ha az összes fizikai állandót szeretné kattinthatóvá tenni.

Amúgy, mi értelme nincs?

Ezzel analóg pl. az a probléma, hogy hogyan érdemes letárolni és megjeleníteni emberek neveit.

Ez tetszik, és számos példát láttam már ilyesmire.

Pl. a brazil rendszerbe hiába próbálta az ügyintéző mindenféle módon beleügyeskedni az ő betűt, azt a rendszer okosan mindig o-ra cserélte. Így a fiam születési brazil papírjai szerint Gergö a neve.

Angliában a születési anyakönyvi kivonatra kell egy családnév, és hiába, hogy a királyi családnak nincs, a nem rég született gyerekeknek valamit be kellett oda írni. Ha jól emlékszem, a Wales vezetéknevet írták be nekik jobb híján.

A feleségemnek és a gyerekeimnek is két vezetékneve van, két különálló szóként. Számos rendszer összevonja a két szót, más rendszerek meg automatikusan kötőjelet tesznek közéjük.

A feleségem egyik utónevét kis betűvel kell írni. Számos rendszer automatikusan nagybetűssé alakítja, mert hát nem nemecsek ernő, ugye.

Igen, tényleg nem egyszerű ez.

Es meg csak szamitogep sem kell hozza...
a nevem: "Susoczki", en legalabbis igy irom. De ahany papir, annyifele. Mas a jogsiban, mas a szemelyiben, mas az utlevelben, mas a TAJ-kartyan.
Hosszu es rovid "o", "i" es "y" valtogatja egymast.

--
http://www.micros~1
Rekurzió: lásd rekurzió.

Kerdes, hogy utani mennyit jarsz Iranban orvoshoz. Mert en itt Magyarorszagon neha intezek ezt-azt es mindig gorcoslnek, hogy miert nem ugyanaz a nev a szemelyiben, mint a jogsiban vagy a szuletesi anyakonyviben es hogy most melyik a helyes. Aztan vegul leszarjak, hogy sztem melyik a helyes, dontenek az egyik mellett. De mindegy, max. otven ev es ezzel sem lesz gondom. Ambar, lehet, hoyg csak husz, nyugdijaskent nem hiszem, hoyg pl. lakashitelt akarok felvenni vagy lakhelyet valzotatni.

--
http://www.micros~1
Rekurzió: lásd rekurzió.

Nem kell acsorogni. Nekem amikor elvesztettem a szemelyi+TAJ kombot, baromi egyszeru dolgom volt: a szemelyihez regeltem az ugyfelkapun egy idopontot, a TAJ-hoz meg odamentem, es kb fel ora alatt vegeztem sorbanallassal (inkabb sorbanulessel), ugyintezessel, mindennel egyutt. Egy delelotton belul inteztem a kettot, es ebbol egy jo ora-ketto volt az utazas (eloszor az onkormi megfelelo reszlege utana meg a Teve utca plusz onnan haza).
--
Blog | @hron84
Üzemeltető macik

ext2-ext4 meg eddig nem hagyott cserben. Hardverhibas (kattogos) vinyot is tulelt, volt ugy, hogy 10.-re tudtam elinditani, es akkor sikerult lementem az adataimet.

FAT, NTFS mar *tobbszor* hagyott cserben. Ntfs-sel olyan elofordult, hogy A-P ig latta a konyvtarakat, S-tol nem (igy a system32-ot sem, igy bootolni se tudott).
Windows-os fajlszerverek egyeb okossag~1 -okat is megcsinalnak. Amitol banki program nem futott, miutan atraktam linuxos Samba ala, igy 2015-ben...
Tobb fajlbol masolatot kellett csinalni 8.3 formatu~1 -ban, es CSUPA NAGYBETU kiterjesztessel :)

Szoval az ext3+ magasan a legmegbizhatobb fajlrendszer nalam.
Az a hangyanyi sebessegkulonbseg meg nem izgat.
ZFS-t ugyan nem probaltam, jokat hallani rola, majd talan egyszer.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

> Azért egy ext2/Fat32-t ne hasonlítsunk már egy ext3/4/NTFS-sel.

Ezt nem tudom, honnan szurted le, hogy egyiket a masikkal hasonlitottam.

Mellekszal:
Gondolom nem kellett meg torolt adatot visszahoznod.

Ext3-nal jartam igy, eleg komoly ugyrol volt szo. Azt lehet olvasni ext2-kent, es eldobod a journalt. Ugy pedig vissza lehet allitani torolt inode-okat.

A maradek volt nehezebb, a torolt fajdarabokbol visszaallitani egy Excel fajlt. Mivel eleg nagy volt a tet, es elegge elorehaladott volt az ugy, igy vegulis osszehoztam. Picit bruteforce, de meglett.

Ext4-et mar nem lehet ext2-kent mountolni, de ezt senki se irta.

Szoval ext3-at azert lehet hasonlitani ext2-vel, ha ugy tetszik:)

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

"Ezt nem tudom, honnan szurted le"

Journaling FS-ek vs kőkorszak.

"Gondolom nem kellett meg torolt adatot visszahoznod."

De kellett. De az nehogy már az FS hibája legyen, hogy valaki balfasz módon törölt valamit. (Egyébként erre NTFS-ben pont van megoldás, ld. VSS és hasonlók, nyilván némi lemezhelyért cserébe.)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

( Zahy v | 2015. 12. 17., cs – 09:06 )

Persze a szokásos kérdések most is felmerültek bennem, hogy
- aki a jelenleg vezető ext*-ra szavazott, az hányféle másikat próbált, használt, tesztelt és mennyire
- és vajon ext3-ra, vagy ext4-re szavazott-e; egész egyszerűn feltételezem, hogy ext2-re nem, bár /boot-nak, meg multiplatform adathordozós FS-nek szerintem is elfogadható a mai napig
?

A "kedvenc" definíciós részével egyetértek, csak a "szerelem első látásra" kitételt technikai dolgok kapcsán nehezen akarom elhinni. Azzal is tisztában vagyok, hogy (majdnem) mindig az elsőhöz hasonlítjuk a későbbieket, de az, hogy megragadjunk a elsőnél (és mondjuk nem visszatérünk hozzá), az kicsit fals. De elfogadom amit írsz, így vedd a kérdésem "hangosan magamban beszélek"-nek.

[x] Ext3

- Próbáltam Linuxon a ReiserFS-t (évekig) és a BTRFS-t (a céges gép most is azon van), az Ext régen elég rosszul teljesített, ha helyre kellett állítani dolgokat a fájrendszerben egy váratlan áramszünet miatt, ez mostanában elég sokat javult. A BTRFS-t sajnos csak annyira használom, hogy erre formáztam be a / -t, és kb ennyi, nem jut időm tesztelni komolyabban a cuccot.
- /boot -ra pedig Ext3-at használok noatime,nodev,nosuid,noexec opciókkal.
--
Blog | @hron84
Üzemeltető macik

"- és vajon ext3-ra, vagy ext4-re szavazott-e; egész egyszerűn feltételezem, hogy ext2-re nem, bár /boot-nak, meg multiplatform adathordozós FS-nek szerintem is elfogadható a mai napig"

Nekem az összes közül kb ez a három a kedvencem. Amikor tformázok valamit, ezek közül választok. Nem igazán tudom elképzelni, hogy másik mi előnyt adhatna nekem. Azt tudom, hogy ezekkel meg vagyok elégedve, ubuntuban/puppyban vannak hozzá toolok (fsck, gparted) amik kezelik, nem volt indíttatásom másra. (mindig megnézem a phoronixen a fájlrendszer benchmarkokat, a többi nem vészesen gyorsabb)

Nem szeretem az ilyen feltételezéseket.

Az ext2 lenyegeben ext3/4 naplozas nelkul, a fajlrendszer ugyanaz. Ext2-bol ugy lehet csinalni ext3-at, hogy bekapcsoljuk a naplozast. Ext4 pedig csak annyira kevessel ter el az Ext3-tol, hogy Ext3-at mountolva Ext4-es modullal egybol Ext4-et csinal belole.

Visszafele is mukodik: ha nem kell naplozas, egyszeruen ki lehet kapcsolni:

tune2fs -O ^has_journal /dev/hdX

Jol jott a RPi-re kotott USB merevlemezen, hogy a naplozas miatt nem porgette fel 5 percenkent.

csak érdekességből xfs és btrfs is volt már gépen, átlagos használat mellett. de amire használom elég az extX, így az a "kedvenc". abból is inkább ext3, mert a virtualbox az ext4-re köpköd. vagy köpködött. journaling meg jól jön néha, így ext2 kiesett.

"Belépés díjtalan, kilépés bizonytalan."
"Vajon mit várok a sorstól, ha hányok az édestől, és izzadok a sóstól."

( trey | 2015. 12. 19., szo – 12:40 )

Magamnak, jövőre:

- exFAT (nem is vártam tőle többet)
+ vmfs

--
trey @ gépház

( nan | 2015. 12. 28., h – 23:32 )

Nem lehetne a listába betenni a QSYS nevű filerendszert is az IBM-től?

( uid_20470 | 2016. 01. 07., cs – 09:58 )

Kedvenc? Mire?

Ext4-et meg ext3-at hasznalok fokent, de ez megint olyan, hogy attol fugg mire szeretned hasznalni, kedvencem nincsen.