"Ne változtass Linux fájlokat Windows alkalmazások és eszközök használatával"

 ( trey | 2016. november 18., péntek - 8:10 )

A microsoftos Rich Turner a minap arról blogolt Bash on Windows kontextusban, hogy miért nem érdemes a %localappdata%\lxss könyvtárban levő fájlokat Windows alkalmazásokkal piszkálni. Ez az infó valószínűleg sokaknak nem hat újdonság erejével, Turner mégis érezte annyira fontosnak megemlíteni, hogy piros, félkövér, "méteres" betűkkel írta bele az internetbe:

DO NOT, under ANY circumstances, create and/or modify Linux files using Windows apps, tools, scripts, consoles, etc.

Részletek itt.

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

Lehet, jobb lenne ha a Windows VHD(x)-n tárolná az ilyen állományokat. Próbálgattam régebben a 2012-es terminál szervert, az is a felhasználói fiókokat VHD-ba pakolta.

Azt is ugyanúgy megpiszkálhatná valaki.

Üdv,
Marci

File metadata (e.g. permissions, ownership, timestamps, etc.) is represented differently in Linux than in Windows. Because stores your Linux files in an NTFS folder, WSL calculates and persists each Linux file’s metadata in its NTFS extended attributes.

However, Windows apps do not know how to (nor that they should) re-calculate & persist this Linux metadata each time they create/modify a file stored under your distro’s root (%localappdata\lxss\).

Therefore, if you use a Windows app/tool/console to create and/or modify a file under your distro root, it won’t have any Linux file metadata (e.g. permissions, owner, timestamps, etc.) stored in its extended attributes.

Akárhogy olvasom a fentieket, nekem ez jön le: Létezik ez az úgynevezett NTFS extended attributes. Ennek semmi köze a linuxhoz azt leszámítva, hogy a linuxos dolgokat is ide rakják, aminek nincs helye máshol. Tehát egy windows specifikus fájlrendszer szintű feature-ről beszélünk, amit a win alkalmazások nem kezelnek?! Javítsatok ki ha tévedek, de ez elég gázul hangzik

Ahogy az is, hogy a hiányzó vagy korruptnak vélt metadata kezelésére a fájl törlésével reagálnak ahelyett, hogy teszemazt újragenerálná a subsystem, vagy valami defaultot használna.

Mert hány alkalmazás kezeli Linuxon default az xattr-t? Annak pont az a lényege, hogy alkalmazás-specifikus dolgokat lehessen bele írogatni, ha akar az alkalmazás. Ha nem akar, nem ír, más rendszer adatait meg nem "illik" írogatnia. (pl. a Samba abban tárolja az NTFS ACL-eket, random más progi és a kernel meg nem foglalkozik vele, ha be van kapcsolva az ACL mapping, akkor a Samba megcsinálja az NTFS ACL -< Unix ACL leképezést, ha nincs, akkor semmi nem fog arról tudni, hogy egyébként arra szabályok vonatkoznak)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

"windows specifikus fájlrendszer szintű feature-ről beszélünk, amit a win alkalmazások nem kezelnek"

Nem az extended attribute-ot nem kezelik, hanem azokat a linux specifikus attribute-okat amit lxss ott tárol. Azaz ha notepad-ben létrehozol egy file-t, akkor nem fogja berakni azokat az attribute-okat ami az lxss-nek kell.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

Értem én, de ennek nem kéne bajnak lennie. Ha nincs ott, képzelje oda a linux subsystem, vagy pótolja valami defaulttal.
Amúgy is szerkesztésről/módosításról volt szó, ebben az esetben pedig elég volna ha szimplán ignorálná/békén hagyná

dehat ignoralja is, errol szol a cikk

--
NetBSD - Simplicity is prerequisite for reliability

"Tehát egy windows specifikus fájlrendszer szintű feature-ről beszélünk, amit a win alkalmazások nem kezelnek?! Javítsatok ki ha tévedek, de ez elég gázul hangzik"

Nem, egy NT (!=Windows) specifikus fájlrendszer szintű feature-ről beszélünk, amit a Win32 alrendszer és alkalmazások nem kezelnek egységesen. A történelemkönyvek szerint az Extended Attributes az OS/2 alrendszer számára került be az NTFS-be.
Win32 alatt szórványosan van csak használva és tudtommal nincs olyan általános szabály a kezelésére, amit be kéne tartani.

Üdv,
Marci

Cygwin-el sosem volt ilyen gondom :)

Jó dehát valahol el kell kezdeni a Linuxos kékhalál kifejlesztését :D

ezen felröhögtem! thx! :D

+1

Akár hogyan is nézzük, gyengén oldották meg a linux jogosultságok tárolását NTFS-en. Azért a Windows->Linux irányban (pl. samba) ennél sokkal jobb kompatibilitás van, még ha vannak néha ott is problémák.

Tudsz példákat mondani arra, hogy milyen hátránnyal jár ez a megoldás?

Üdv,
Marci

[troll]Pl. nem szabad a WSL fájljait a "host" rendszerből módosítani... :)[/troll]

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

A konkret hatrany szamomra az, hogy jo lenne pl. git-bol ugy ki- es becsekkolni, hogy a verziokezelo altal eltarolt jogosultsagok megmaradnak. Ezt a WSL-en belul meg tudom csinalni, de pl. egy IDE-t nem tudok WSL-en beluli fajlokkal hasznalni a posztban leirt problema miatt.

----------------------
while (!sleep) sheep++;

És ha WSL-ben NTFS-en tartod ezeket a file-okat a /mnt/c/ alatt, akkor elvész ez az eltárolt jogosultság?

Üdv,
Marci

Ez érdekes kérdés.
A WSL /mnt/c alatt az NTFS ACL-ek egy valamiféle 9 bites projekcióját adja az aktuálisan belépett felhasználó szemszögéből nézve.
Nem biztos, hogy ezt vegyíteném a git permission kezelésével.

Engem nem érdekelnek a git jogosultságok, /mnt/c alatt dolgozok Bash alól vim-ben a pet projektemen, Win32-es SourceTree-vel kezelem a git repot. Teljesen jól működik.

(Persze a Linux-os git mindent modified-nak és nem staged-nek lát ugyanezen repon, sztem az újsorok miatt. De ez hidegen hagy.)

Az ujsorokat meg lehet oldani.

Viszont a permission-okkel az a fajdalom, h peldaul az Ansible 1.x nem volt hajlando +x-es inventorykkal dolgozni. Meg rengeteg egyeb.

----------------------
while (!sleep) sheep++;

Igen, el.

----------------------
while (!sleep) sheep++;

Sztem pedig egy nagyon jó megoldás született. Az NTFS létező funkcióit használják fel arra, hogy egy másik alrendszer integrálódjon, és mindenféle egyéb trükkösködés nélkül.

A cikkben leírt dolog valóban probléma. De ez is megoldhatónak látszik.

Ami kapásból eszembe jutott az a következő:
Az lxss folder (ahol az egész cucc leledzik) és tartalmának jogosultságait az user profile jogosultságaiból örökli, nincs megtörve sehol az inheritance. Az NT tud olyat, hogy mindenféle virtuális usereket kezel. Pl. egy IIS application poolnak vagy egy Windows Service-nek (alias daemon) is egy egyedi usert "generál" (pl. IIS AppPool\site vagy NT SERVICE\TrustedInstaller). Gyakorlatilag a "kódhoz" rendeli a jogosultságokat nem a belépett felhasználóhoz. Atom biztonságos megoldás.

Azaz:
1. "Generálna" egy LXSS\{currentuser} felhasználót
2. lxss folderen megtörné a jogosultságokat
3. A {currentuser}-nek adna az lxss-re read jogot, az LXSS\{currentuser}-nek meg read+write-ot. Leörököltetne.
4. Bash alól minden hívás, filesystem access kernel drivereken megy keresztül, ami tudna fordítani az IO manager-nek, hogy minden műveletet az LXSS\{currentuser} végez {currentuser} helyett
5. A sima Win32 alól a {currentuser} csak olvasni tudna

Akár így, akár máshogy az MS is megoldhatja a problémát, addig meg ésszel kell használni.

"Ne változtass Linux fájlokat Windows alkalmazások és eszközök használatával"

Hogy jön ide az NTFS? Ki az aki linuxot telepít NTFS fájlrendszerre és windows alól piszkálja??
Windows alól Linuxos fájlokat úgy lehet módosítani, hogy először kell egy progi, amivel látni lehet a linuxos partíciókat: http://www.ext2fsd.com/
Ha valami probléma van, akkor az ext2fsd-ben van valami bug. Amúgy meg a soremelés kocsivissza lehet még probléma, amit úgy is szoktak hívni, hogy "Windows-os enter" meg "Linux-os enter".

____________________________________
Ha vita van, számoljanak órajelciklusokat. Egyesével.

Hogy jön mindez a témához?

"amit úgy is szoktak hívni, hogy "Windows-os enter" meg "Linux-os enter"."
Kik? Mikor? Hol?

Üdv,
Marci

Uhh
--
blogom

Egy másik kontextusban igazad van, de a topic teljesen másról szól.

Gizikét kevered a gőzekével.
A szezont meg a faxommal.

Azt ugye tudod, hogy a szálban a Linux Subsystem for Windows-ról van szó, ami pontosan azt jelenti, hogy egy Ubuntu telepítés ott figyel az NTFS fájlrendszeren?