Vlákno názorů k článku
Chyba v Git klientech ohrožuje Windows a OS X od Pali - Okrem toto systemy od Apple maju nejaky zonam...

Ona je spíš otázka, proč by měl být FS case sensitive. Přinese to něco uživateli, nebo mu to zbytečně zkomplikuje život? Na Unixech samozřejmě o uživatele nikdy nešlo, takže chápu že to nikdo neřešil :)

Je to jednodušší pro uživatele. Mě naopak uniká výhoda toho, když na Unixech názvy souborů "2014-12-01 tax office letter.docx", "2014-12-01 Tax Office letter.docx", "2014-12-01 tax office letter.DOCX" a "2014-12-01 Tax Office letter.DOCX" označují čtyři různé soubory.

Souhlas, výhoda case-insensitive FS je dnes menší než bývala. I case-sensitive FS máte na Linuxu předpokládám stejně fulltextově indexovaný (včetně názvů souborů) jako case-insensitive. Nicméně uživatelé jsou case-insensitive, takže když tak pracuje i FS, je to pořád ještě jistá výhoda.

Ad nemožnost vytvořit si soubor "PRN.sdf" - PRN je rezervované jméno zařízení. Když si na Linuxu zkusíte uložit soubor pod jménem /etc/sda, asi to taky moc nedopadne :)

Unixy tradičně nepoužívají přípony ve jménu souboru, tečka je znak jako každý jiný. Ve světě DOSu, OS/2 a Windows se jméno souboru skládá z base name (myfile) a extension (txt). Tak proto :)

Ad /etc/sda - OK, tak /dev/hda1, ono je to celkem jedno. Některá jména souborů jsou prostě rezervovaná, na Unixech stejně jako v DOSu, OS/2 a Windows. Detaily se zjevně liší, koncept je stejný.

Koncept je stejný: některá jména souborů jsou použitá pro přístup k zařízením. Liší se jejich jména, včetně toho jestli je cesta součástí rezervovaného jména souboru.

Device file se tváří jako soubor, ale jde o interface pro driver. Takový je koncept. Jestli je rezervované jméno dané plnou cestou, názvem souboru, nebo třeba nějakým prefixem, to na konceptu nic nemění.

PRN je jedno z DOS Devices v Object Manageru (je to symlink na device). Existující DOS Devices můžete zjišťovat pomocí funkce QueryDosDevice(), a přidávat/rušit přes DefineDosDevice().
http://msdn.microsoft.com/en-us/library/windows/desktop/aa363908(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/aa365461(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/aa363904(v=vs.85).aspx

Symlinky PRN, CON, NUL atd. zakládá Session Manager při startu session. Jejich seznam najdete v registry, větev "HKLM\SYSTEM\Cu­rrentControlSet\Con­trol\Session Manager\DOS Devices"

Pokud jste se ptal jak ve Windows přejmenovat, přesunout či smazat device file, tak jste dostal odpověď.

Pokud jste se ptal jak ve Windows přejmenovat, přesunout či smazat soubor s názvem shodným s device file, tak už to tu bylo popsané.
http://www.root.cz/zpravicky/chyba-v-git-klientech-ohrozuje-windows-a-os-x/527391/

Samozřejmě je to do jisté míry omezující. Ale v praxi nějak nebývá potřeba nazývat soubory AUX, PRN, NUL apod, protože to není dostatečně popisné.

Nechápu. proč bych si nemohl někde na disku uživatele soubor pojmenovat AUX, často by se mi to hodilo/líbilo. Protože je to logické jméno k tomu, co by obsahoval.

Jediné štěstí je, že ten polovičatý pasystém z minulého století jménem Windows nepoužívám, tak takové pitomé problémy nemám. :)

Jak jsem psal, můžete si zařízení AUX smazat z nastavení Session Manageru v Registry, a nebude se pak vytvářet.

Pozadí celé věci je trochu složitější. API CP/M a první verze DOSu používalo FCB, kde se jméno souboru a přípona (8.3) uváděly v datové struktuře zvlášť. Takže když jste chtěl otevřít zařízení AUX, otevřel jste soubor se jménem AUX (přípona se nejspíš ignorovala). DOS v dalších verzích přešel z FCB na handles, takže jste mohl otevřít i AUX:, nebo třeba C:\DEVICES\AUX, kdyby něco takového MS implementoval.
Z tohoto důvodu jsou dodnes kvůli zpětné kompatibilitě jména souborů AUX, PRN atd. rezervovaná. Samo o sobě to není tak špatný nápad, ale nechápu k čemu to je na 64-bitových systémech, kde 16-bitové aplikace ani nespustíte, a těch 32-a-64-bitových, které používají tyhle devices a zároveň je otevírají jako AUX a nikoliv AUX:, je nejspíš nula nula nic.

Soubory v /dev jsou soubory, ne vyhrazená jména:

kass ~ # cat >/dev/hda1
TOHLE JE UPLNE NORMALNI SOUBOR
kass ~ # cat /dev/hda1
TOHLE JE UPLNE NORMALNI SOUBOR
kass ~ # rm /dev/hda1

Windows\System32\svchos­t.exe je device file? Není. Tak proč ho sem taháte? To není možné, toto...

Myslím, že jsi nechopil pointu. Zkus se zamyslet nad tím, proč tu cestu napsal tak, jak ji napsal...

Aneb není nad kvalitní argument :)

Co by taky mel blbovi psat...

Kdyby se radši soudruzi v Redmondu věnovali testování hotfixů.

Záplata na opravu záplaty, hotfix na odinstalaci hotfixu, který znemožnil instalaci a odinstalaci jakýchkoliv hotfixů - tahle záplata měla zajistit denní místo týdenní kontroly revokovaných certifikátů (v Mrkvošrotu asi ještě nevynalezli cron :-DDDD), ale místo toho rozjebala vše od aktivace přes UAC po ovladače grafik od AMD, tisíce spokojených zákazníků ...

Další zmršený patch? Abychom nakonec nedopadli jako na Ubuntu :), kde je takový menší zázrak, když po updatech všechno funguje.
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1404558

Jistě, ve Windows se ještě nikdy nestalo, aby po aktualizaci dostaly BSOD. Ten zásadní rozdíl je, po jakých aktualizacích se to stává ve Windows a v Linuxu. Aktualizace, která mění frekvenci kontroly certifikátů, tohle v Linuxu fakt nezpůsobí.

Mimochodem tohle jádro mám i s nativní IPv6 konektivitou a nepadá. A i kdyby to padalo, tak při příštím startu v GRUBu vyberu starší a padat to přestane. Umí už tohle i Windows? (Ne, Poslední známá konfigurace rozhodně takhle dobře nefunguje.)

Ad Aktualizace, která mění frekvenci kontroly certifikátů, [BSOD] v Linuxu fakt nezpůsobí - nezpůsobila ho ani ve Windows.

Ad tohle jádro mám i s nativní IPv6 konektivitou a nepadá - některé problémy se projevují jen ve specifických konfiguracích nebo způsobech použití. Například 500-bytový leak při otevření handlu vám na serveru způsobí OOM (ať žije OOM Killer), kdežto na stanici si ho nemusíte vůbec všimnout.

Ad při příštím startu v GRUBu vyberu starší [jádro] a padat to přestane. Umí už tohle i Windows - tohle ne. Ale můžete jednoduše odinstalovat patch. Pokud systém nebootuje, můžete použít Systém Restore, tj. vrátit systém do stavu k vybranému datu/času (neovlivňuje to dokumenty). To se dá udělat i z instalačního média. Umíte už na Linuxu něco takového?

aufs alebo snapshoty (systemoveho FS, kde nie su dokumenty)

Jinými slov na Linuxu nic takového neumíte, ale můžete si to dobastlit doma. To nic moc.

Podobně by to chtělo se zamyslet nad postupem upgrade na novou verzi distra. Odhlédneme od toho, že by upgrade měl vždy projít bez problému; to se bohužel nepovede vždycky ani ve Windows. Ale když už upgrade distra v půlce selže, je poněkud nešťastné, když nechá systém rozvrtaný. Co takhle vrátit všechny změny zpátky, jako to dělají Windows?

on je rozdil jestli neco dobastlit lze a lehce (gnu/linux),
nebo dobastlit nelze ci tezce(widle)

nacrt:
lvcreate newroot
rsync / /newroot
chroot /newroot
do-release-upgrade

vysledek, budu mit k dispozici stary system a novy system, novy nijak neovlivni stary, muzu si vybrat pri startu, muzu pustit aplikace stareho (v chroot nebo virtual) v bezicim novem a obracene, mam jasne oddelene oba systemy, muzu ten starty zkopirovat na disk totalne jineho hw a pokracovat v pouzivani tam, atd, atd.... zabere to o nekoloik desitek GB mene nez na widlich, casove o nekolik hodin ci dni rychlejsi...

zkuste toto s windows a schvalne jestli to dobastleni zvladnete zutomatizovat na max 100 radku txt scriptu pro cmd.exe ci powershell :)

Takže si pořídíte kopii systému na jiný volume, a budete upgradovat tu? To můžete samozřejmě udělat i ve Windows. Náčrt:
- Založit nový volume
- Pomocí DISM tam přetáhnout image disku
- Upravit boot entries

Následně můžete zabootovat jeden nebo druhý systém, a upgradovat ho. Samozřejmě to nemá moc smysl, protože upgrade v případě problému provede sám o sobě rollback. Pochopitelně je good practice před upgradem udělat zálohu (nejlépe image), čistě pro jistotu.

Pár dalších věcí o kterých možná nevíte:
- Pokud se nechcete patlat s DISM CLI, můžete si stáhnout GUI.
https://ndde.codeplex.com/releases/view/4828
- Můžete si pořídit snapshot systému v současném stavu, klidně upgradovat něco dělat cokoliv jiného, a v případě potřeby si snapshot přimountovat.
http://blogs.msdn.com/b/adioltean/archive/2008/02/28/a-simple-way-to-access-shadow-copies-in-vista.aspx
- Windows lze instalovat do VHD image, a ten lze bootovat přímo z boot manageru.
http://technet.microsoft.com/en-us/library/hh825689.aspx
- Windows lze nainstalovat tak že máte komprimované instalační zdroje na jedné partition (.wim), a na druhé jen linky do těch .wim souborů. Jinými slovy Windows pak běží z komprimovaných instalačních médií sloučených s tím co uživatel na systému doinstaloval nebo změnil, a snadno může systém revertnout na factory default.
http://technet.microsoft.com/en-us/library/dn594399.aspx

Doporučil bych spíš lvcreate --snapshot oldroot newroot. rsync běžícího systému nemusí dopadnout dobře pro databáze.

nezpůsobila ho ani ve Windows

A ten patch výše uvedený tedy dělal co?

některé problémy se projevují jen ve specifických konfiguracích nebo způsobech použití. Například 500-bytový leak při otevření handlu vám na serveru způsobí OOM (ať žije OOM Killer), kdežto na stanici si ho nemusíte vůbec všimnout

Nevšiml jsem si toho ani na serverech.

Ale můžete jednoduše odinstalovat patch. Pokud systém nebootuje, můžete použít Systém Restore, tj. vrátit systém do stavu k vybranému datu/času (neovlivňuje to dokumenty). To se dá udělat i z instalačního média. Umíte už na Linuxu něco takového?

Takže potřebuju instalační médium? Jak to dělají uživatelé notebooků?

Na Linuxu to samozřejmě umíme a můžete si dokonce vybrat. Bud btrfs snapshoty, a pokud nevěříte btrfs, tak můžete použít LVM snapshoty, anebo pokud vám stačí snapshotovat jen nastavení a starší verze stáhnout z internetu (protože se nepoužívá debilní systém patchů jako ve Windows, tak jde stáhnout libovolná starší verze), tak etckeeper a aptitude. Navíc to skutečně funguje, protože to snapshotuje celý systém (všechny programy i systémová nastavení, bez domácích adresářů uživatelů), windowsí System Restore ze zkušenosti moc nefunguje, právě protože obnovuje jenom vybrané soubory a mnoho 3rd-party ovladačů se neregistruje.

Ad nezpůsobila ho ani ve Windows; A ten patch výše uvedený tedy dělal co - kolega linkoval dva problémy s aktualizacemi pro Windows:
- Cumulative security update for Internet Explorer. We are aware of some reports of functional issues on sites that use nested modal dialog boxes on Internet Explorer 11 that occur after you install this security update. To resolve this issue, install update 3025390.
https://support.microsoft.com/kb/3008923
- December 2014 update for Windows Root Certificate Program in Windows. The Windows Root Certificate Program enables trusted root certificates to be distributed automatically in Windows. Usually, a client computer polls root certificate updates one time a week. After you apply this update, the client computer can receive urgent root certificate updates within 24 hours. We have found that this update is causing additional problem on computers that are running Windows 7 Service Pack 1 (SP1) and Windows Server 2008 R2 SP1. This includes the inability to install future updates.
http://support.microsoft.com/kb/3004394

Ani jeden z těch patchů nezpůsoboval BSOD.

Ad potřebuju instalační médium? Jak to dělají uživatelé notebooků? - použijí instalační médium z USB klíčenky. Některé notebooky by měly mít recovery media předinstalovaná, takže by mělo stačit zabootovat z nich. Osobně ty recovery partitions vždycky mažu, SSD disky jsou ještě pořád poměrně malé a nemám na nich zbytečné místo.

Ad na Linuxu to samozřejmě umíme a můžete si dokonce vybrat - jak psal psal, musíte si to zbatlit doma. Out of the box nic jako System Restore nemáte. Snapshoty vám nepomůžou u dister která mají uživatelské adresáře na jednom FS se zbytkem systému. To se týká například Ubuntu, které by default dělí disk jen na /swap a /. Etckeeper vám sice někdy možná umožní se dostat z problémů, ale rozhodně to není alternativa k System Restore.

Ad System Restore ze zkušenosti moc nefunguje, právě protože obnovuje jenom vybrané soubory - to bylo za Windows XP. Od Visty výše se monitorují všechny typu souborů ve všech cestách. Aplikace nemusí nic registrovat. Nejvýš před instalací mohou vytvořit System Restore Point, aby byl označený čas do kterého se uživatel může chtít vrátit.

Snapshoty vám nepomůžou u dister která mají uživatelské adresáře na jednom FS se zbytkem systému. To se týká například Ubuntu, které by default dělí disk jen na /swap a /.

btrfs má koncept subvolumes, které sdílí oddíl (a volné místo), přičemž každý subvolume se snapshotuje zvlášť. V Ubuntu jsou ve výchozím nastavení uživatelské adresáře v jiném subvolume než zbytek systému, právě aby se to dalo snapshotovat.

A ono Ubuntu používá jako default btrfs? Btrfs pokud vím není stable, takže by to byla celkem loterie.
https://btrfs.wiki.kernel.org/index.php/FAQ#Is_btrfs_stable.3F

Snapshotovat btrfs samozřejmě můžete. Když si to naskriptujete (BTW chtělo by to trigger, aby instalace vynutily snapshot), a v případě problému se v těch snapshotech ručně pohrabete, tak to asi půjde. Ale patlat doma něco nad unstable FS je dost jiný level, než prostě v GUI vybrat "chci se vrátit k datu X hodině Y".

Nevím, Ubuntu jsem už dlouho neinstaloval (aktualizace fungují dobře), ale asi ještě ne.

Když si přečtete tu pragmatickou odpověď (dva roky starou!), zjistíte, že se od použití libovolného souborového systému moc neliší. Pro většinou použití je btrfs stabilní, problematický je RAID-5 a 6. Já ho postupně používám na všech serverech, které aktualizuji na nový Debian (btrfs jde vytvořit z existujícího ext*), a funguje to dobře. V Debian Jessie a Ubuntu už ani není označené jako experimental.

Trigger i možnost se vracet (a mazat staré zálohy) poskytuje balíček apt-btrfs-snapshot,

Ekvivalent k vytvoření "PRN.sdf" by byl, kdybych si na linuxu vytvořil soubor "sda" - ne "/etc/sda" (a mimochodem obojí samozřejmě lze). I ty jeden demagogu...

K čemu je to dobré, když Windows nepoužívají žádnou normalizaci? Takhle sice nemůžete mít v jednom adresáři soubory pokusný.docx a Pokusný.docx, ale klidně můžete mít pokusný.docx a pokusný.docx (to první obsahuje U+00FD, to druhé U+0079 U+0301).

Normalizaci provádí aplikace. Mimochodem na každém FS který podporuje Unicode můžete mít pokusný.docx a pоkusný.docx, kde to 'o' v druhém názvu souboru je U+043E (Cyrillic Small Letter O).

Napsat tam cyrilici není tak snadné jako napsat tam jméno po NFD. Stačí, když aplikace provádí nějakou Unicode normalizaci (třeba kvůli vyhledávání v dokumentu), a najednou vám z toho vypadne úplně jiné jméno souboru (třeba pokud se generuje z prvního odstavce jako ve Wordu).

Takže souhlasíte, že case-insensitive filesystem stejně uživatele mást bude?

Zkusíte mi najít nějaký scénář, kde by podobný problém hrozil? Vstup z klávesnice vrací NFC, a neviděl jsem aplikaci, která by vracela cokoliv jiného.

Třeba copy&paste z nějakého webu nebo PDF. Občas takové weby a dokumenty (navíc používající font, který si s rekompozicí neporadí) vídám.

Bohužel jakmile začnete normalizaci provádět, začne být round-trip značně problematický. Zapsal jste na disk pokusny´.docx, při čtení adresáře dostanete pokusný.docx, a neshoda může způsobit problém.

Je to úplně stejný round-trip, jako když zapisujete Pokusný.docx a on už existuje pokusný.docx.

To je dobrý argument, ale s case insensitivity aplikace počítají (pokud odhlédneme od chyby Gitu).

Tak by počítaly i s normalizací. Prostě je to ve Windows zase jen takové polovičaté, nic to neřeší a jen to přidává další problémy.

Každé jiné řešení by bylo horší.

V čem? Pokud jde o uživatele, je lepší NFD. Pokud jde o vývojáře, je lepší case-sensitivity.

Jinak konkrétně tento problém může nastat u aplikace, která se snaží odstraňovat či detekovat háčky a čárky. To se snadno dělá v NFD.

Proč????? Jednoznačnost.

Nedávno jsem byl konfrontován s jedním tvůrcem systemd, podle kterého je POSIX už jen zbytečná zátěž. Nyní frčí Linux_API. Kompatibilita s POSIX stále ještě zůstává zachována, ale s tím, jak je tlačen systemd do Linuxu se obávám, že spíše dříve než později bude jeho podpora "pro dobro lidstva" obětována.

Navíc mě naštval "Pali" s jeho názorem, že není chyba Gitu, že si nevšimli, že MS Windows ani OS X nejsou "ten správný POSIX". Prostě už dnes Git funguje správně jen na Linuxu, přesněji řečeno "Linuxové verzi POSIXu" (ale to víme, že GNU už od počátků má pár věcí "by default" ne-POSIXově, ne?).

Odstaní se nejspíš všechny znaky kategorie Cf (bohužel jsem nenašel dokumentaci, kde by to bylo jasně specifikované).

POSIX nikdy nezaručoval, že dva řetězce budou nutně identifikovat různé soubory, třeba .git/config a ./.git/config jsou jeden a tentýž soubor. Správně byste měl použít realpath, která vrátí převedené jméno.