HOVD 2015 - Kedvenc fájlrendszer

 ( trey | 2016. január 4., hétfő - 19:14 )
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

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

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ó.

A fájl egy teljesen elfogadott magyar szó, ilyen írásmódban is.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

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ó.

Nem :)

azt hiszem, a teljesen elfogadott alatt azt kell érteni, hogy megüt egy bizonyos, elég nagy elfogadottsági szintet

Nem, azt kell érteni, hogy a magyar helyesírás szabályai szerint helyes.

szerintem arra gondolt, amit én írtam.

Miután nevergone eggyel később a helyesírásra utaló linket írt, így ezt már tényként kezelhetjük, hogy mire gondolt, úgyhogy de :)

http://helyesiras.mta.hu/helyesiras/default/suggest?q=f%C3%A1jl

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

És? A helyesírási szabályzat vonatkozó pontjait is megnézted?

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

azt amelyiket Romárióék patchelgetik?

probaltal azert utananezni, hogy megis mire hasznal a zfs annyi memoriat?

--
"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)

Nagyjabol. Eppen azert mondom, hogy normal esetben egy gepen ertelmetlen szamomra. Direkt storage feladatra mar oke. Akkor viszont nem altalanos filerendszer, hanem celgep filerendszere.

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

Tehát nem sikerült megértened, amit olvastál.
Akkor miért nem azt írod, ahelyett hogy itt terjesztesz fud-ot?

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. :)

FreeBSD nem csak a ZFS fájlrendszert ismeri.

teenyleg?! nahat...

tudom, de miert lenne jobb nekem gmirror/gstripe/graid5 + ufs kombo??
ennyi erovel lehetne mdadm+ext3/4 binugzon is.

ugye egyetertunk, hogy a zfs az egeszen mas, mint ezek, es ugye nem kell kulonosebben megindokolnom, hogy miert valtottam zfs-re???

Nem tudtam, milyen elvárásaid vannak, és úgy tűnt, mintha a zfs memóriaéhsége miatt akarnád a FreeBSD-t "leváltani".

Hát ezen a (ZFS-es, 6 GB RAM-os) gépen egy jó ideje már 10-es FreeBSD van.

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!"

Ha a bsd-d rakoncátlankodik, azért miért a zfs-t hibáztatod?
Ha hangoskodik a szomszédod, felrobbantod a háztömböt, csak hogy csend legyen?

mi a javaslatod, mi legyen?
10.2-es freebsd -n szar a zfs arc kezelése.
mit javasolsz tehát?

Solarist! :-D #troll
--
Blog | @hron84
Üzemeltető macik

de már lentebb leírtam, hogy miért nem jó nekem a solaris.
egyéb?

Note the smiley and the hashtag. :-)
--
Blog | @hron84
Üzemeltető macik

szétröhögtem az agyam.

É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ó.

Vállalati felhasználás (volt) az elsődleges célja, ahol nem a RAM drága, hanem az adatvesztésből származó üzleti kár.
------------------------
{0} ok boto
boto ?

Az implementáció is lehet rossz, nem biztos, hogy a zfs by design sok ramot igényel.

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!"

El kéne már felejteni ezt a "felhasználó nem hangolja" dolgot. Hangolja magát a rendszer, azért van a gép, hogy dolgozzon.

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

+10000

-1
Legyen benne az FS-driverben egy teljes AI-rendszer, de ne egye fel a világ összes memóriáját. Khm.

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™

Pontosan ez a use-case rendszerint. Boot idejére van csak ott a removable media, mint "slusszkulcs". Nekem sincs szükségem rá, de ettől másnak még lehet...
------------------------
{0} ok boto
boto ?

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.

Vagyis, fogod a zfs-t, lábonlövöd a geli-vel, meg még egy kriptó-réteggel, hogy esélye se legyen tudni mindent a diszkekről, amit egyébként tudna...
Majd ezután sírsz, hogy szar a zfs.

Értem.
Nagyon érdekes!

?
geli+zfs az egy supported felállás.
geli-n kívül milyen mégegy crypto réteget látsz?
nem szar a zfs, de faszér' zabálja fel az arc a memóriát annyira, hogy az oom_killer megölje a rendszert...

mit javasolsz?

Os upgrade, arc_max és swap beállítás. Ezzel menni fog jól.
--
zsebHUP-ot használok!

arc_max-ot beállítottam karácsony környékén, azóta nem borult meg.
köszi!

Ebben az esetben a win 10 a te barátod :)

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

xfs?

> 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

Vagy faszkorbáccsal szétcsapni a csapatban, hogy ki és miért hagyta jóvá ezt.

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

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.

+1

Jeeez, már megint itt az ms-haccsereg.

Nem akarnátok rögtön a 8.3-as szabályt is megvéde~1 ?

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...?

Azt mond már meg plz, hogy ebben mi volt az ntfs/ms/windows/whatever megvédése? De most komolyan.

http://hup.hu/szavazasok/20151213/hovd_2015_kedvenc_fajlrendszer#comment-1938991

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)

FYI: OSX alatt a HFS+ se nagyon szarakodik a kis-nagybetű közötti különbséggel, maximum a bash a path completionnál.

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

+1.

HFS+ az case-INsensitive filerendszer.

AAA és aaa és Aaa és aAa és aaA stb.stb. sileok ugyan azok.

SŐT!
lehet a HFS+ -t case sensitive -re formázni, érdekes kísérlet egy ilyenre telepíteni az OS X -et. :) nem fog működni. :)

De, mukodik

oszinten szolva mountail lion -t raktam egyszer veletlenul case-sensitive hfs+ -ra, azzal voltak problemak.
errol az apple is ir, hogy nem biztos, hogy fog mukodni.
talan a yosemite es el capitan mar rendbe van rakva ilyen teren...

[nem ide]

Nem akarjuk megvédeni, mert a 8.3-as nevezéktan idejétmúlt, semmi keresnivalója a mai világban. Akárcsak a case-sensitive fájlrendszereknek.

lock.

Szerk.: Remélem a case-sensitive változóneveknek azért még van.

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

minden esetben, amikor case-sens adatokat akarunk file-nevnek adni

Amik például a következők:
...?

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

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....

Attól, hogy case-insensitive a fájlrendszer, még simán lehet használni kis- és nagybetűket. A howtoRenameFilenameToCaseInsensitiveMadness.gif NTFS-en is létezhet.

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

egyszerűen nem tudok ellenállni a bait threadeknek :(

mindig elkövetem azt a hibát, hogy beleugrok ezekbe a vitákba

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

Nem kevertem semmit ossze:
http://hup.hu/szavazasok/20151213/hovd_2015_kedvenc_fajlrendszer#comment-1939154

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....

jaj ugyan ne szedd ennyire a lábad. inkább gondolkozz el azon, hogy itt, egy mellesleg case-sensitivityről szóló threadben miféle megfontolásból beszélsz 2015-ben arról, hogy neked egy konkrét 1994-es LFN implementáció fáj, meg eleve mi köze a kettőnek egymáshoz :)))

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.85).aspx#namespaces

Üdv,
Marci

@mrceeka alakitsd at a linket, pl. valami linkroviditovel, a Drupal linkesitoje nem lelkesedik a zarojelekert. Btw, ez is egy eleg elborult dolog, hogy a MSDN URL-ekben mindig van zarojel... de ebbe mar bele se szeretnek menni.
--
Blog | @hron84
Üzemeltető macik

Így is a jó oldal nyílik meg. A többihez meg nem sok közöm van: a Drupal azért lelkesedik, amiért szeretne, a kérdéses URL pedig valid.

Üdv,
Marci

Nem a validitasra celoztam, hanem hogy nincs ertelme a zarojelezesnek, erre a celra az MS-en kivul senki nem hasznalja ezt a konstrukciot, okkal.
--
Blog | @hron84
Üzemeltető macik

Wikipediat lattal mar?

É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.

Íratlan szabvány nem szabvány, csak valami mendemonda. Aki íratlan szabványokra építkezik és elvárja, hogy más betartsa, az ostoba.

Egyébként jelen esetben a Drupal szarja le nagy ívben az írott szabványt.

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

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?

A zárójel teljesen valid karakter URL-ben, még percent-encoding sem kell hozzá. Lehet szidni a Microsoftot, de ez esetben ők járnak el szabványosan. Inkább treynél kopogtass, hogy szar a Drupal 5.

Érdekes, mert ha én kimásolom az URL-t, akkor nekem átalakul:

https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247%28v=vs.85%29.aspx#namespaces

Egyébként meg ha valaki ad magára, akkor ilyen linket csinál:

Naming Files, Paths, and Namespaces | Namespaces

--
trey @ gépház

> á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

ugyan már, miért is jelennének meg jól a microsoftra vagy a wikire mutató linkek. Hogy te növeld a SEO-jukat, blaszfámia!

(ez a d) eléggé mellbe vágott. Nem birom felfogni)

Szarafirefox, me' átalakíccsa!

--
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™

Ja, rendkívül zavar.

Inkább az zavar, hogy egyesek itt milyen hangnemet engednek meg maguknak a havcsik előtt és milyen ki nyuszik lesznek, ha privátban kell írni.

--
trey @ gépház

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

+1

+1

-------
It is our choices that define us.

"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™

például képek (festmények), zenék, könyvek, dokumentumok.

Ha pl.
Ω.txt -ben az Omega együttesről akarsz írni
ω.txt-ben pedig a szögsebességről
:-)

És ez szerinted real world use-case vagy valami erőltetett példa? :)

----------------
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.

kutya.jg, macska.jpg, ló és macska.jpg esetleg ló_és_macska.jpg, Lódarázs.jpg, Ló és darázs.jpg, stb.stb.stb.stb......

IGEN IGEN erőltetett példák. :)

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.

+1, valamiért mindig a "legnagyobb" "IT" "szakértőktől" kapom a leghülyébb írásmóddal leírt, legkevésbé beszédes nevű fájlokat.

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!

" Állítsd át az IFS változót, és akkor majd nem fog szeparálni! "

mit és hogyan?
a meglevő bash scriptek nem fognak eltörni?

Abban a szkriptben állítsd át, amelyikben probléma van a szóköz menti tördeléssel, és valahogy így:

OLDIFS="$IFS"
.....
IFS='¬'
# zűrös rész
.....
# zűrös rész vége
IFS="$OLDIFS"

Vagy persze nem értem a kérdést.

"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ó.

Az én értelmezésemben a pont a mondat végét jelzi, az aláhúzás meg kiemelésre való.

Fuszenecker Róbert

Idézet:
a pont a mondat végét jelzi

Akkor a kiterjesztés neked új dolog lesz :)

Nyilván nem új dolog.
Csak rá akartam világítani: az eszköz van értünk vagy mi vagyunk az eszközért?

Fuszenecker Róbert

Nyilván értem, mire céloztál, de annyira adta magát, hogy nem hagyhattam ki a választ :)

Nekem anno ('91 korul) az alahuzas semmire sem valo volt, mert ismeretlen volt szamomra.
De az akkor DOS-okon megtanultam, hogy a filenevben hasznalhato, mint spec. karakter.
Szoval ez meg onnan jon nekem.

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

> En nem latom, miert olyan bonyolult szokoz helyett alahuzast vagy pontot rakni a filenevbe.

Mert az emberek által beszélt nyelvben a szóköz az elválasztókarakter, nem az aláhúzás. ;)

Beszélt nyelv vs. karakter: emlékeim szerint a beszélt nyelvben hangok vannak :P

Persze, ertem. Ezert volt jo a CLI, amiota GUI van, azota vannak ilyen gondok, mert mar mindenki gephez ul :)

--
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?)

"Ezt a *X világ és a CLI lehetővé teszi. "

És az mivel elfogadottabb, mint a szóköz?

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

*É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....

Idézet:

"Viszont itt illik megkulonboztetni a kis es nagybetuket."

tudom, már kijelentetted hogy az okosabbakkal nem állsz szóba, de az utókornak mégis ideírok pár "nehéz szót":

https://en.wikipedia.org/wiki/Case_sensitivity
https://en.wikipedia.org/wiki/Case_preservation

> Van\\olyan,fajlom:amit| egyszeruen>nem.eszik.meg.a.windows*,es.nem.ertem.miert?.txt

Egy fájlnévnek nem lehet része path separator vagy wildcard karakter? Skandallum! ;)

Mintha SQL-ben akarnál létrehozni * nevű mezőt. :)

Nálam előfordult már, hogy különféle forrásból érkező fájlokat egy könyvtárba másolva (azt hiszem, talán backup készült) egyszercsak azt mondta a rendszer, hogy hoppá, ez már létezik.
Persze nem ugyanaz volt, de csak kis/nagybetűben tértek el.

Másik példa cyrill betűknél:

P.txt: Parkolókról szóló leírás
Р.txt: Rádiókról szóló leírás oroszul

Ha valaki nem venné észre ez szabályos case insensitive rendszereknél is, mivel a második egy nagy orosz cyrill R betű.

Ugyanez.

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

Inkabb masikat mondok:

Main.java es main.java. Igen, fasz az a programozo aki ilyet csinal, de letezo dolog.

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...

Pl. a fényképezőgépem .JPG-t gyárt. A szerkesztett képet mellé tudom rakni .jpg-ként és később nem kell másik mappában kotorászni érte.

--
openSUSE 13.1 x86_64

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.

Miért akarnám a komplett képtárat kimásolni valakinek? Értem én mire gondolsz, csak nekem nem az az igény.

--
openSUSE 13.1 x86_64

"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.

De akkor ne álljunk meg itt, mi van akkor, ha én ugyanazon a fájlneven több fájlt akarok tárolni? Úgy rémlik, van olyan os és fs, ami ezt engedi.

Esetleg erre gondolhatsz: https://en.wikipedia.org/wiki/Files-11

http://a.te.ervelesi.hibad.hu/csuszos-lejto

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

Miért is?

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!

Telefonban nem kell mondani, hogy mi a kisbetű, és mi a nagybetű, akárhogy írja be a júzer, mindenképpen jó lesz :-)

Fuszenecker Róbert

Biztos vagy ebben? Rengeteg szó van, amit másként mondunk és másként írunk. :)

sms :)

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

Volt már valahol itt a HUP-on egy "ámokfutás" arról, hogy igazából a kisbetű és nagybetű az írásunkban is teljesen felesleges, mivel kimondva úgyse "látszik" (hallatszik), hogy mi a kicsi és mi a nagybetű.

Oh. My. God.

/o\

Mondjuk belegondolva tök igazad van. A Google és a hasonló webes keresők megmutatták, hogy totál felesleges a struktúrált fájlkezelés, ha van egy jó keresőd úgy is megtalálod. ;)

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

Azért az látom nem zavar meg, hogy nem írtam a strukturált fájlkezelés feleslegességéről.

Tovább vittem a csúszós lejtődet.

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

Pld egy takarékos egyedi fajlnévvel akarok elmenteni valamit (lásd YouTube link), ahol az a és az A nevű fájl nagyon nem ugyanaz?
--
zsebHUP-ot használok!

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 pont az az architektúra van jól kitalálva, ahol minden fájlművelet előtt, közben és után transzformálni és ellenőrizni kell az átadott paramétereket, mert a karakterek és karakter tömbök természetes implementációja case sensitive?

--
https://portal.gacivs.info

- áh, mindegy -

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

Case sensitive fájlrendszeren mindig is könnyebb a case insensitive működést megoldni, mint fordítva. Egyébként az NT-nél lett volna rá lehetőség.

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Javanal mikor lesz a visszafelé nem kompatibilitás eldobása? Mondjuk a java.net.URL kivezetése és hasonlók.

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?

"A funkcióját betölti, miért kellene kivezetni?"
Mert van helyette jobb, az URI class. Ugyanúgy, miért kéne kivezetni a case-insensitive filerendszert, a funkcióját betölti.

"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

Még mindig: az NTFS case sensitive. Az, hogy a Win32 API case insensitive, az egy dolog. Arról lehet beszélni. De az NTFS case sensitive.

"Még mindig: az NTFS case sensitive."

Még mindig: tudom.

"Az, hogy a Win32 API case insensitive, az egy dolog. Arról lehet beszélni."

Nem csak a Win32 API, hanem az összes API, ami nem a POSIX layer-en át kezeli a fájlokat.

Most akkor az NTFS-nél az jó, hogy case sensitive, minden más fájlrendszernél rossz?
Ebben a szálban aki a case insensitive mellett kardoskodik, azoknak az NTFS-t is rossznak kellene tartaniuk, nem?

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.

+1

"a backward compatibility miatt sok minden legacy dolog létezik, amivel együtt kell élni."
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...

Üdv,
Marci

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

"Az egész szál erről szól,"
Nem, az egész szál a case sensitive/insensitive fájlrendszerről szól.

Arról szól, hogy miért case insensitive módon használunk egy case sensitive filerendszert, majd ennek a magyarázata (backward compat) az, amit mindenki figyelmen kívül hagy. Az NTFS még mindig case sensitive.

Mondj már egy példát erre, hogy ha case sensitive-ként használnánk a case sensitive fájlrendszert, akkor mi nem működne, ami korábban működött!

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.

Mert ugye a matematikában is csak egyféle ábrázolása van egy számnak...

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

"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."

Idézet:
Mondj már egy példát erre, hogy ha case sensitive-ként használnánk a case sensitive fájlrendszert, akkor mi nem működne, ami korábban működött!

Megfogtál, nem tudok egy példát se :)

Olvass már egy hozzászólással feljebb is, akkor észreveheted, hogy nincs elírás.

Hm? persicsb hozzászólására gondolsz? Ott nem látok semmi olyat, ami magyarázná, hogy miért írtad el direkt.

(Ha esetleg még nem vetted észre, kétszer írtad le ugyanazt :) - nem tartom számon, ki mit írt, de gondolom, hogy a másodikból kimaradt egy "in")

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").

Szerintem nem volt elírás és persicsb korrekt példát hozott.

Üdv,
Marci

Már leesett, köszi :)

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.

+1
Ezzel teljesen egyetértek! :)

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).

Jujj. Asszem, most koppant. Fogjuk arra, hogy már este van, jó? :)

Folyamatosan vezetik ki a dolgokat.
Először deprecated-re állítják, majd később valamikor törlik.
Az URL nem ugyanaz, mint az URI, lásd ezen kettő doksiját.

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]

"Szerk.: Remélem a case-sensitive változóneveknek azért még van."

Hááááát...

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

Ezt ugye te magad se gondolod komolyan, ugye nemecsekernő

Pascal köszöni szépen, elvan nélküle is.

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

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.)

ebbol is lehet orbitalis nagy szopo, es modnja mr meg nekem valaki, hogy miert jo ha letezik a myIteritor es a MyIteritor kulon-kulon valtozokent?!
aztan az ezredik sorban meg napokig debuggolsz, hogy mi van ebaszva, mert nem az az eredmeny, aminek lenni kene...

Mondjuk nem PHP-t, JavaScriptet és hasonló szarokat kellene használni, hanem normális programnyelveket, ahol az ilyenért már a compiler visít ;)

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

Kihagytad a C-t. :P (a programozót nem a programozási nyelvnek kell(ene) kijavítani :))

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)

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

A filenév is adat.

"oooo..... OS X is case INsensitive fs-t hasznal"

OS X filerendszerre legfeljebb elrettentő példaként lehet hivatkozni.

"A filenév is adat."

mehetünk még feljebb, a merevlemezek nevét is vehetjük adatnak.
e tekintetben a filenév nem adat, hanem annak a filenak a neve, amiben a számítógépes adataidat tárolod.

"OS X filerendszerre legfeljebb elrettentő példaként lehet hivatkozni."

mesélj!

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

case sensitive vs case insensitive a téma.

(halkan jegyzem meg, hogy modern, desktop rendszereken minden file-ra tudsz tag-eket (plaintext metadata) tenni, amit indexel kulon a fajlrendszer...)

Milyen standard (pl. POSIX) eszközökkel lehet ilyen tageket létrehozni, lekérdezni, módosítani?

tudok egy olyna unix rendszerrol, ami modern, szep, mukodik, es ezt tudja.
nem tudom hogy posix eszkozok kozul melyeket hasznlaja a motorhazteto alatt, de nem is erdekes.

Szóval nincs olyan, kár.

nem azt mondtam, hanem azt hogy nem tudom es hogy nem is erdekes.
(amugy 1985-os dolog a POSIX, lehet hogy akkor meg nem is gondoltak ilyenre, es tulhaladott lett? nem tudom.)

Szerintem ez pl. pont tárolható extended attribute nevű szarban, annak is a user névterében, amit aztán Linux alatt pl. ha jól tudom a VFS-rétegben implementáltak, azaz van mindenütt. FreeBSD alatt UFS-en és ZFS-en is van. Többi rendszert nem tom.

amirol egyebkent beszeltem, az az os x es a hfs+, valoszinu, hogy extended attributesban tarolja ezeket a szarokat.
egyebkent maga a rendszer unix certified es posix kompatibilis.

Ja, nekem egyből a KDE ugrott be a maga metaadataival, indexelésével és keresésével.

Persze fogalmam sincs, hogyan tárolja és azt se tudom, hogy KDE-n kívüli eszközökkel elérhetőek-e ezek valahogy.

http://hup.hu/szavazasok/20151213/hovd_2015_kedvenc_fajlrendszer#comment-1940086

ezt irtam: "tudok egy olyna unix rendszerrol, ami modern, szep, mukodik, es ezt tudja."

milyen unixon fut kde? ;-)

Én 5.x-es Tru64-en futtattam KDE-t. No jó, nem tegnap volt.

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.

konklúzió?

konklúzió az, hogy a KDE-sek szerint a KDE Unixokon elérhető, viszont nem tudom neked megmondani, hogy pontosan melyik Unixokon.

Már megijedtem, hogy a magyar IT szakma krémjének a metaadat szó sem jut eszébe. Már csak addig kellene eljutni, hogy az mit is jelent (része-e az adatnak a metaadat), és a fájlnév az metaadat-e.

Idézet:
"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?

Idézet:
Idézet:
"mert masra hasznalod, es mert jelzel vele valamit?"

oooo.... atlathato, karbantarthato kod rulz!

igen.

Ez egy elég rossz példa amúgy, mert eltérő egy osztály neve és egy referencia neve nem ugyanolyan dolgot jelöl, míg két fájlnév igen. Pl. a fordító kontextus alapján simán meg tudná különböztetni a kettőt akkor is, ha pont ugyanaz a nevük.

+1, jobb helyeken meg is különbözteti, még a kódkiegészítés is tudja az IDE-ben, hogy melyik melyik

-1
Nem rossz a példa, mert fájlrendszernél a fájlnév is eltérő dolgokat jelöl, pl. fájl, könyvtár, link.

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ó, ...

jovanakko'

+1

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)

hát éppen ez az, hogy nem kódolok file-névbe adatot, arra valók a meták. Viszont, míg neked windows alatt csak egy konyv.epub-od lehet egy mappában, addig nekem, linux alatt, különböző méretű betűkkel, akár 2^9 is :P

Pl. kisbetűvel tudod a változóidat jelezni, nagy betűvel az osztályaidat és tudsz olyat csinálni, hogy az Iterator osztály egy példányát iterator-nak tudod elnevezni.

Hasonló példa a fájlrendszernél, ha a könyvtáraidat nagybetűvel kezded, a fájlokat meg kisbetűvel.

És miért kellene a könyvtáraimat nagybetűvel és a fájlokat meg kötelezően kicsivel írnom? Egy zeneszámnál miért írjam kötelezően kisbetűvel pl? Stb.

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

mert német vagy, és a németeknél a könyvtár nagybetűvel, a melléknév meg kisbetűvel írandó.

Nincs, sőt, jelszavaknak is case insensitive-nek kellene lenniük.

azoknak nyilvan valoan nem szabad case insens -nek lenniuk, te is tudod, hogy ez hulyeseg, es nem errol van szo.
a filenevek nem jelszavak, egeszen masrol beszelsz, alma es korte esete...

Pontosan tudom, miről beszélek, és tökéletesen igazad van az almával és körtével: mivel közeli rokonok, ezért nagyon helyes, hogy a filerendszerek is case sensitive-ek.

szerintem egyaltalan nem helyes. (alma es korte nem kozeli rokonok, mindossze novenytanilag a rozsafelek csaladjaba tartoznak.)
a jelszo, nem hasonlithato a filenevhez ebben a kontextusban.

No offense, de ne játszd az ostobát plz.

Itt kezdted.

És hogy sikerült a linkelt kommentből eljutni a jelszavakig? Eh, mindegy, itt fejezzük be szerintem.

A linkelt komment megírása előtt kellett volna...

Jó, akkor ne fejezzük be.

És hogy sikerült a linkelt kommentből eljutni a jelszavakig?

A C# miért használ például case sensitive class neveket? Amiket aztán kellően nagy szopás jól tárolni egy case insensitive fájlrendszeren...

Példa:

public class Customer
{
//valami
}

public class customer
{
//másvalami
}

A fenti a mintát Te helyesnek tartod, használod és másoknak is javaslod, ezért merült fel a kérdés Benned? Nem értem pontosan a használati esetet.

Üdv,
Marci

Nem ez a kérdés.

A kérdés az, hogy miért terveztek egy nyelvet teljes mértékben case sensitive alapokon, amikor alatta az elsődlegesen használt platform és annak a fájlrendszere case insensitive.

--
https://portal.gacivs.info

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.

"Csak hogy tudd: C# az nem Java."

Tudom.

"Itt nem kötelező a filenévnek a class nevével megegyeznie."

Nem kötelező, de akkor is úgy nevezed általában, ami az osztály neve... :)

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."

> "Itt nem kötelező a filenévnek a class nevével megegyeznie."

Nem kötelező, de szeretettel szoktam megemlékezni azokról, akik nem így csinálják :-(

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.

Nem, sikerült túlhaladni rajta. Azonban még mindig nem hallottam valós technikai érveket a case sensivity mellett, leszámítva pl. a török localet.

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

Miért, a törököknél mit okoz?

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

Idézet:
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.

A helyes megoldás az lenne, ha ezek a karakterek nem az asciinak megfelelő i és I karakterekkel lennének írva, onnantól locale független a dolog.

Egyébként eszembe jutott még egy történet ami a témába vág.

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?

Idézet:
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ó.

Engem az iráni egészségügy "Magyar Robtarsa"-ként tart nyilván, mert a shirazi kórházban (ISO 9001:2000!) a néni rossz sort (Magyar Köztársaság) másolt ki az útlevelemből, ami egyrészt nem fért ki, másrészt az orvosnál vagy a röntgenen vki félreolvasta...

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ó.

Amúgy nem kötelességed új TAJ/jogsi/bármit kérned, ha rossz nevet/szül.időt írnak rá?

Passz. Az utobbi harminc evben (miota szemelyim van), ez jart a legkevesbe a fejemben. Akar a halal hivatalokban acsorogni.

--
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

Csak kerdem, hogy a HFS/NTFS kopkodes az a Linuxos implementaciok sebesseget meltatja, vagy a nativet? Mert annyi a kulonbseg a nativ meg a Linuxos implementacio kozott, hogy ha elzongoraznam, hangverseny kerekedne belole.
--
Blog | @hron84
Üzemeltető macik

nativat, NTFS-t pedig nem a sebessege miatt szidtam (top 3 leggyorsabban benne van tudtommal)

Nem is sebesseget, minoseget akartam irni, csak bezavart a hatterben zajlo beszelgetes a kollegak kozott. Bocs.
--
Blog | @hron84
Üzemeltető macik

En mereseim szerint amugy ntfs es ext4 nagyjabol hasonlo sebessegkategoria, hfs+ van mindkettotol csunyan merhetoen lemaradva

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....

"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."

Ilyenem nekem is volt, pont ugyanezert szerettem, ellenben az inode elfogyas tenyleg nagy szopas rajta.

> ellenben az inode elfogyas tenyleg nagy szopas rajta.

Kellemetlenseg, igen. De nem adatvesztes.

---
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....

Melyik fs-nél lehet inode elfogyáskor újakat hozzáadni?

(Szerencsére az elmúlt 20 évben nem fogyott el alólam inode még, de érdekel)

Hát ha nem is hozzáadni lehet, de dinamikus allokálású a(z amúgy Linuxon is elérhető, de kereskedelmi) vxfs - azaz Veritas Extended FileSystem.

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

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

ahogy FAT-ot se NTFS -sel, meg ext2 -t se ext4 -gyel, stb.
megy a hupszakertes.

> 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™

(x) ods-1, ods-2, ods-5

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
?

Az első kérdésed másik HOVD-s topikokban is fel lehetne tenni.

Célszerűbb lenne, ha minden szavazásnál azt kellene megmondani, hogy az illető elemet szeretem-e, nem szeretem-e, közönbös vagy nem ismerem.

Fuszenecker Róbert

Ugye nem a legjobb, hanem a kedvenc a kérdés.

Lehet valami úgy is kedvenc, hogy elsőre azt próbálta az ember, mindent tudott, gyors volt és azóta is tart a szerelem.

(én idén nem ext-re szavaztam)

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."

Magamnak, jövőre:

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

--
trey @ gépház

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

Azt nem.
( https://xkcd.com/468/ )

Kedvenc? Mire?

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

Linux:ext4, FreeBSD:zfs.