Fórum Ubuntu CZ/SK
Ubuntu pro osobní počítače => Obecná podpora => Téma založeno: Martin Šácha 14 Června 2010, 16:22:45
-
Zdravím,
potřebuji ve scriptu (/etc/gdm/PostSession/Default pro nezničitelný desktop) vymazat z uživatelského profilu všechno kromě adresáře .VirtualBox, protože by návrat do původního stavu trval při zpětném kopírování 2+GB souborů docela dlouho. :(
Googlil jsem nějaký "výjimkový" přepínač u příkazu rm, ale nic jsem neobjevil :(
Kdo prosím pomůže?
-
tu su ponuknute dake riesenia > http://ubuntuforums.org/showthread.php?t=513195
[popripade ak nieje nutne menit nastavenia virtualboxu beznym uzivatelom a virtualne disky niesu ulozene v tomto priecinku tak by mu mozno stacilo zmenit prava]
-
Napadá mě jednoduché
rm -r `ls -a /home/xyz | grep -v '.VirtualBox'`
(rm bere jako argument i seznam souborů/složek, takže mu je předhodím z ls a grepem akorát vyřadím ten .VirtualBox, ale možná to jde i jednodušeji)
-
Napadá mě jednoduché
rm -r `ls -a /home/xyz | grep -v '.VirtualBox'`
(rm bere jako argument i seznam souborů/složek, takže mu je předhodím z ls a grepem akorát vyřadím ten .VirtualBox, ale možná to jde i jednodušeji)
Jasný, takže jsem si úspěšně vymazal vnitřek správce (mě) a lama kterou jsem chtěl vymazat to nechalo byt, ikdyž jsem v /home/xyz změnil název dobře :(
PS. Já *censored* zapoměl na "cd /home/xyz"...hmmm potěšující
-
cd /adresář && find . -delete
-
$ find /home/xyz/ -path '/home/xyz/?*' ! -path '/home/xyz/.VirtualBox*' -delete
@arrange
tos' mu mohl rovnou poradit $ rm -R /adresář :P
-
Špatně jsem pochopil zadání, beru zpět, sorry.
-
Zdravím,
potřebuji ve scriptu (/etc/gdm/PostSession/Default pro nezničitelný desktop) vymazat z uživatelského profilu všechno kromě adresáře .VirtualBox, protože by návrat do původního stavu trval při zpětném kopírování 2+GB souborů docela dlouho. :(
Googlil jsem nějaký "výjimkový" přepínač u příkazu rm, ale nic jsem neobjevil :(
Kdo prosím pomůže?
Já bych to udělal využil hard linků (Wikipedie (http://cs.wikipedia.org/wiki/Pevný_odkaz)) - skriptem nebo jakkoli jinak vytvořit linky na ty největší soubory (předpokládám, že jde o virtuální disky, images apod.) a umístit je někam mimo ten smazávaný adresář (musí to být na stejném filesystému). No a potom to nechat klidně vymazat, a při kopírování zpět vytvořit hard linky na původní místo.
Snad jsem se vyjádřil srozumitelně.
-
Já bych to udělal využil hard linků (Wikipedie (http://cs.wikipedia.org/wiki/Pevný_odkaz)) - skriptem nebo jakkoli jinak vytvořit linky na ty největší soubory (předpokládám, že jde o virtuální disky, images apod.) a umístit je někam mimo ten smazávaný adresář (musí to být na stejném filesystému). No a potom to nechat klidně vymazat, a při kopírování zpět vytvořit hard linky na původní místo.
Snad jsem se vyjádřil srozumitelně.
Ano, jde o disky, image a snapshoty.
Nebude ale rm ty odkazy následovat, respektive proč na stejném FS, když odkaz může vést kamkoli (mluvím o soft linku, který by nezpůsoboval problémy při změně cíle)?
-
Ano, jde o disky, image a snapshoty.
Nebude ale rm ty odkazy následovat, respektive proč na stejném FS, když odkaz může vést kamkoli (mluvím o soft linku, který by nezpůsoboval problémy při změně cíle)?
Nebude, a právě v tom je ten rozdíl mezi hard a symbolickými linky. Doporučuji přečíst alespoň na wikipedii hesla Pevný odkaz (http://cs.wikipedia.org/wiki/Pevný_odkaz) a Symbolický odkaz (http://cs.wikipedia.org/wiki/Symbolický_odkaz).
O tom, jestli rm (ne)následuje symlinky (u hard linků o něčem takovém nemůže být řeč, protože všechny linky jsou si rovny, narozdíl od "originálu" vs. symlinku) se dá dočíst (resp. nedočíst, protože rm to prostě nedělá) např. na manuálové stránce rm (http://unixhelp.ed.ac.uk/CGI/man-cgi?rm)
Edit: doplnění:
mluvím o soft linku, který by nezpůsoboval problémy při změně cíle
problémy při změně cíle? nerozumím, problémy můžou vzniknout právě u symbolických linků, když se "originál" někam přesune, a symlink tedy odkazuje "do prázdna".
-
Právě že jsem to četl oboje :)
Z wikipedie o hard linku:
Při aktualizaci programů, na které odkazuje více pevných odkazů, je potřeba nejprve smazat všechny odkazy a teprve pak vytvořit nové soubory. Pokud by byl smazán jen jeden odkaz a vytvořen nový soubor, bude původní druhý odkaz obsahovat starší verzi programu (souboru). Jak bylo výše uvedeno, nalezení všech odkazů může být náročné. Z tohoto důvodu se obvykle místo pevných odkazů používají raději symbolické odkazy.
Rozumím tomu dobře že si hardlink někde uchová změnový stav na který potom ukazuje? Mě to přijde trochu blbost ale...
problémy při změně cíle? nerozumím, problémy můžou vzniknout právě u symbolických linků, když se "originál" někam přesune, a symlink tedy odkazuje "do prázdna".
Ano ale nenalezení je snad menší problém než ,,kolize" pevných linků.
-
Z wikipedie o hard linku:
Při aktualizaci programů, na které odkazuje více pevných odkazů, je potřeba nejprve smazat všechny odkazy a teprve pak vytvořit nové soubory. Pokud by byl smazán jen jeden odkaz a vytvořen nový soubor, bude původní druhý odkaz obsahovat starší verzi programu (souboru). Jak bylo výše uvedeno, nalezení všech odkazů může být náročné. Z tohoto důvodu se obvykle místo pevných odkazů používají raději symbolické odkazy.
Rozumím tomu dobře že si hardlink někde uchová změnový stav na který potom ukazuje? Mě to přijde trochu blbost ale...
Tady ale jde o jednu věc. Uživatel vytvoří soubor L1, který bude interně ve filesystému směřovat na jeho konkrétní inode (inode1). Potom vytvoříš hard link k souboru L1, který se bude jmenovat L2. Soubor L2, resp. jeho záznam ve filesystému, bude směřovat na ta původní data, tedy (inode1), a v záznamu toho inode1 se zvýší počet odkazů na daný soubor o jedničku. Mimochodem tenhle počet pevných odkazů na soubor vypisuje i ls - dám jednoduchý příklad, na kterém je to vidět:
$ ls -l
celkem 0
$ touch soubor1_link1 # vytvořím "originál č. 1"
$ ls -l
celkem 0
-rw-r--r-- 1 donny users 0 14. čen 20.34 soubor1_link1
$ touch soubor2_link1 # vytvořím "originál č. 2" - jiný soubor
$ ls -l
celkem 0
-rw-r--r-- 1 donny users 0 14. čen 20.34 soubor1_link1
-rw-r--r-- 1 donny users 0 14. čen 20.35 soubor2_link1
$ ln soubor1_link1 soubor1_link2 # vytvořím link z "originálu č. 1", všimni si ve výpisu ls, že se zvětšil čítač linků u soubor1_link1 a soubor1_link2
$ ls -l
celkem 0
-rw-r--r-- 2 donny users 0 14. čen 20.34 soubor1_link1
-rw-r--r-- 2 donny users 0 14. čen 20.34 soubor1_link2
-rw-r--r-- 1 donny users 0 14. čen 20.35 soubor2_link1
$ rm soubor1_link1 # odstraním "originál č. 1", hard link na ten originál stále zůstává, akorát se mu zmenšil čítač linků zase na 1
$ ls -l
celkem 0
-rw-r--r-- 1 donny users 0 14. čen 20.34 soubor1_link2
-rw-r--r-- 1 donny users 0 14. čen 20.35 soubor2_link1
$ mv soubor2_link1 soubor1_link1 # tady přejmenuju "originál č. 2" na "originál č. 1"
$ ls # tady jsou teď dva různé soubory, soubor1_link2 je ta "starší verze", o které se tam píše
celkem 0
-rw-r--r-- 1 donny users 0 14. čen 20.35 soubor1_link1
-rw-r--r-- 1 donny users 0 14. čen 20.34 soubor1_link2
//edit - ještě se můžeš u těch výpisů ls podívat na čas modifikace, resp. to 20.34 a 20.35, podle toho poznáš, který soubor je který, jinak u toho původního (a jeho hardlinku) jsem zvýrazňoval hard link count červeně.
-
Jasný. Takže když v /home/xyz/.VirtualBox/HardDisks/ vytvořím hardlinky na soubory umístěné někde jinde (mimo /home/xyz) tak se smažou pouze hardlinky?
Mimochodem lze hardlinky zálohovat, nebo se budou muset znovu vytvořit pomocí ln?
Nelze, tar hardlinky následuje, což nechci.
-
Zkusím to vysvětlit ještě jednou. Ve filesystémech jako je ext2 nebo ntfs existují tzv. pevné odkazy (hard link).
Představ si to tak, že každý soubor dat je tvoří (na úrovni filesystému) tzv. i-uzel (metadata souboru, viz obrázek (http://upload.wikimedia.org/wikipedia/commons/d/d7/Soubor_Inode_(czech_description).png)). To ale není vše, protože ještě se k tomu souboru uživatel musí nějak dostat, tzn. musí se nějak jmenovat a být "uložen" v nějakém adresáři.
Je fakt, že ke každý soubor se nachází v nějakém adresáři (nejvýše v kořenovém). A adresář je vlastně taky soubor, který obsahuje záznamy - dvojice: jméno souboru a číslo inode.
Když tedy přiřadím inode do nějakého adresáře pod nějaký název, vznikne mi počítačový soubor.
Co se stane, když vytvořím hard link. Inode, který už je takto přiřazen k nějakému názvu a do nějakého adresáře, přiřadím ještě zároveň do jiného adresáře k jinému názvu. Budou to tedy dva různé počítačové soubory s naprosto totožným obsahem. Mezi nimi se nedá nijak rozlišovat (jednotlivé hard linky jsou si rovny). Když vytvoříš hard link(1) k velkému souboru a ten první potom vymažeš, data (inode) se nevymažou, protože zůstanou ještě u jiného souboru (u hard linku(1)). Pak je jednoduché vytvořit zase hard link toho hard linku(1), pojmenovat ho jako ten původní velký soubor, a máš po problému. Hard linky se nedají následovat už z jejich podstaty.
Oproti tomu symbolické odkazy (symlinky) jsou vlastně to samé jako zástupci (*.LNK) na Windows (s tím rozdílem, že na linuxu jsou podporovány přímo ve filesystému, na Windows v Průzkumníku). Jsou to malé samostatné soubory, které obsahují odkaz na jiný existující (cílový) soubor. Když se cílový soubor přejmenuje nebo přesune/smaže, symlink je tzv. mrtvý - ukazuje na neexistující místo. Při práci (na linuxu narozdíl od windows) je uživateli jedno, jestli pracuje s originálem nebo se symlinkem, jediná potíž může být při zálohování nebo kopírování. Pokročilejší nástroje umí tzv. sledovat symlinky, tj. zálohovat/kopírovat(/vypalovat na dvd ...) ty originální soubory namísto oněch symlinků (je to logické, k čemu je mi vypalovat symbolické odkazy, když po vypálení stejně nebudou fungovat, to radši nechám sledovat symlinky a vypálit místo symlinků ty soubory, na které je odkazováno).
No a když už to takhle zdlouhavě řešíme, proč se na to nepodívat jednoduše - velké soubory prostě PŘESUNOUT do jiného adresáře na stejném filesystému (který se nebude mazat) - to nebude trvat ani sekundu, protože s inodem a samotnými daty se nebude hýbat, a potom je PŘESUNOUT zpátky
:D :D :D
-
Aha, já už to vyřešil softlinkem (parametr "-s" u ln), který vytvoří několikabytový soubor který se lehce zálohuje.
Ty velké soubory jsem přesunul jinam, to nebyl problém.
Hard linky se nedají následovat už z jejich podstaty.
Tak si to vyzkoušej. Udělej si hardlink na nějakej velikej soubor a ten link zakomprimuj tar-em. Vytvoří se ti velkej archiv, a to je přesně to co jsem nechtěl. To rovnou můžu komprimovat originál. Velkej archiv se extrahuje delší dobu než malej archiv a když mám script v PostSession a uživatelé se střídaj každou chvíli (školní učebna), nikoho by nebavilo čekat půl hodiny na extrakci ;)
Donny, díky za snahu (K++) ale vyřešeno :)
-
sachy, dík :) no já jsem si tím taky toho ohledně těch linků spoustu osvětlil. Ještě poslední dodatek - hard linky se nenásledují (jde mi o ten výraz), ty prostě jsou, o tom to je. každý soubor sám o sobě je (hard) link - link na nějaký inode (a je v podstatě jedno, jestli na některý z inodů směřuje víc linků), to jsem se snažil vysvětlit, proto nějaké "následování" je beze smyslu. Jak to tak u mě občas bývá, tak jsem se do toho ponořil tak, že jsem začal vynechávat podstatu problému. Samozřejmě, že asi nejideálnější řešení je přesunout velké soubory jinam a zálohovat jenom jejich symlinky :)
-
Njn posledních pár přípěvků už jsem si tím ,,následováním" taky nebyl tak jistý, ale lepší jednoduchý výraz mě nenapadl tak jsem u toho zůstal. ;)