Ubuntu Sverige

Ska flytta ut en /home till separat partition. Wikin (http://ubuntu-se.org/wiki/Howtos/Separate_home) säger: Vad gör kommando nummer två? Varför inte bara köra cp -r /old/home /new? Eller då kanske senaste ändringsdatum uppdateras och det vill man ju inte. Däremot borde det väl gå bra med rsync -a /old/home /new?

Jadu, vette katten varför man gör så, har inte alls koll på kommandot. Men för mig har det tidigare aldrig vart några problem att kopiera hela katalogen till den nya partitionen och montera den som /home.

Jag visste att det var nåt lurt med det! Kommandot fuckade upp behörigheten på några filer, bland andra .ICEauthority så jag fick fel när jag försökte logga in. Får göra om det, men den här gången blir det med rsync

m!rage skrev:Ska flytta ut en /home till separat partition. Wikin (http://ubuntu-se.org/wiki/Howtos/Separate_home) säger:

Kod: Markera allt

cd /old/home
find . -depth -print0 | sudo cpio --null --sparse -pvd /new/
sudo mv /old/home /old/home_backup
sudo mkdir /old/home

Vad gör kommando nummer två? Varför inte bara köra cp -r /old/home /new? Eller då kanske senaste ändringsdatum uppdateras och det vill man ju inte. Däremot borde det väl gå bra med rsync -a /old/home /new?

Vid tiden för att denna wikisida blev aktuell, hade det diskuterats en del här inne på forumet. Det var åtskilliga medlemmar som hade installerat Ubuntu, men inte hade tänkt på fördelen med att ha en separat /home-partition. Vi ville ge dessa nytillkomna en möjlighet till att fixa till "den missen" i efterhand.

Lars, systemadministratör, tog då och kopierade rakt av (mer eller mindre, vill jag minnas) från psychocats och dennes hemsida. Författaren där, skriver bla så här, angående detta kommando (kopierat från sidan):

Yes, one of those lines looks really complicated—so please copy and paste the commands into the terminal instead of retyping them.

Note: I have tested the second command myself, and it works, but some have pointed out it might make sense to preface the commands with sudo in case one of the other users has subdirectories manually marked as unreadable to the user making the move. Since I have not tested this out and all directories and readable to all by default, I'm offering this as only an alternative in case the command as given does not work:
sudo find . -depth -print0 | sudo cpio --null --sparse -pvd /new/

Så, för att inte göra det allt för komplicerat, följde man vid denna tid, ett exempel som bevisligen funkade korrekt för envar.

Psychocats är tämligen erkänd i Ubuntu-sfären, så det kändes OK att följa dennes råd och tips.

För en mer erfaren, finns med stor sannolikhet ytterligare sätt att genomföra det hela på ett bra sätt. Detta var, vad "vi" valde vid den tidpunkten. Lars skall väl iofs tala för sig själv, men det var ingen annan, som då, hade en avvikande uppfattning om att källan var bra.

Tukken

Tackar (något sent) för det uttömmande svaret. Tror ni det är OK om jag ändrar i Wikin till rsync istället? Vad jag vet följer det med som standard i Ubuntu numera

m!rage skrev:Tackar (något sent) för det uttömmande svaret. Tror ni det är OK om jag ändrar i Wikin till rsync istället? Vad jag vet följer det med som standard i Ubuntu numera

Nu är jag inte riktigt säker...
Men jag tänka mej att om man vill flytta sin home-mapp till en helt egen partition, så är det önskvärt att alla filrättigheter bevaras för att undvika problem.

Det går säkert att lösa på mer än ett sätt...

Ett lite annorlunda sätt att flytta en home-mapp (eller vilken directory-hierarki som helst) från ett ställe till ett annat, är: Jag har inte provat det nu, men det fungerade alldeles utmärkt för några år sedan iaf...

Nu är jag ingen expert på Linux...
Men finns det inget lämpligt argument till kommandot "cp" för att bevara filrättigheterna?

Det är önskvärt att både rättigheter och ändringsdatum bevaras när /home flyttas. Vad jag vet är det inte möjligt med cp. Varför inte göra det enkelt för sig och använda rsync? Syntaxen är hur enkel som helst: Bevarar allt man vill. Kan kompletteras med -vh --progress för att ge status om hur det går

Anledingen till att cpio används är att få med specialfiler också. Tror du behöver mer än -a till rsync för att det ska fungere helt och hållet...

Jag kör med rsync -plrD i min backup. Men det kan ju vara olika beroende på vilka program/desktop som körs.

mcNisse skrev:Anledingen till att cpio används är att få med specialfiler också.

Japp, print0 (ut) och null (in) är till för att även få med specialtecken i filnamn vilket varken cp eller rsync (tror jag) klarar.

Rune.K skrev:Nu är jag ingen expert på Linux...
Men finns det inget lämpligt argument till kommandot "cp" för att bevara filrättigheterna?

Från manualen för cp

-p same as --preserve=mode,ownership,timestamps

--preserve[=ATTR_LIST]
preserve the specified attributes (default: mode,ownership,time‐
stamps), if possible additional attributes: cont

Men har varit med om att filer trots attributet --preserve inte bevarats intakta.

@mcNisse

-a, --archive archive mode; equals -rlptgoD (no -H,-A,-X)

@Bowmore: vad för specialtecken? åäö och liknande unicode?

m!rage skrev:@mcNisse

-a, --archive archive mode; equals -rlptgoD (no -H,-A,-X)

Hittade denna nya guide PartitioningHomeMoving med rsync istf find/cpio

Den rekommenderar denna variant på rsync Känns ju inte mindre krånglig än find/cpio men bevarar timestamps etc.

@m!rage
Nej, inte åäö utan andra tecken t.ex nyrad.
Den typen av filnamn under home verkar dessutom bara finnas i katalogen .gvfs

Fast jag kan förklara exakt vad den raden gör. Däremot har jag inte en aning om vad den gör. Så jag tycker nog att rsync har en lättare syntax ändå
rsync -x kan ju också vara bra att använda ifall man har konstiga symlänkar i hemmappen som leder till andra hårddiskar. -S betyder tydligen "handle sparse files efficiently" vad nu det innebär. EDIT: läste på...
Men då ändrar jag till i wikin om det verkar OK?

Vad print0 gör är att lägga till tecknet null i slutet på filnamnet för att få ett unikt sluttecken utifall det skulle finnas nyrad-tecken i filnamnet som normalt är sluttecken för filnamn. Parametern null talar sen om för cpio att null är sluttecken för filnamn.

Här en annan beskrivning på sparse
http://en.wikipedia.org/wiki/Sparse_file

Det här är ett mycket intressant problem; hur man bäst kopierar en hel katalogstruktur och samtidigt bevarar den så intakt som bara är möjligt. Vi har nu 5 förslag i tråden. För att lättare kunna jämföra har jag tagit mig friheten att ändra så att alla 5 varianterna nu kopierar från och till samma ställen som i det första inlägget...
Jag har testat dessa förslag noga under Lucid beta2 och har kommit fram till följande resultat:

cpio tar cp -r rsync -a sudo rsync -aS
protected files - - - - ok
dense files - ok ok ok -
sparse files ok - ok - ok
directories ok ok ok ok ok
block devices ok - - - ok
character devices ok - - - ok
named pipes ok ok ok ok ok
sockets ok - ok ok ok
symbolic links ok ok ok ok ok
hard links ok ok - - -
file owner - - - - ok
member group - - - ok ok
other group - - - - ok
permission bits - - - ok ok
access timestamp - - - - -
modify timestamp - ok - ok ok
change timestamp - - - - -
security context - - - - -
trusted attributes - - - - -
user attributes - - - - -
access control lists - - - - -

Det som bevaras markeras med "ok" och det som inte bevaras markeras med "-" i tabellen.

protected files är lässkyddade filer, samt filer i läs- och/eller listskyddade kataloger.
dense files är vanliga filer som inte är sparse.
directories är vanliga kataloger.
file owner är filens ägare.
member group och other group är filens grupp som man är respektive inte är medlem i.
permission bits är läs/skriv/kör-rättigheter samt setuid/setgid/sticky bit.
access timestamp är tidpunkten när någon senast läste från eller skrev till filen.
modify timestamp är tidpunkten när filen senast ändrades.
change timestamp är tidpunkten när filens metadata senast ändrades.
trusted attributes är som user attributes, men kräver root-rättigheter.

Vi ser direkt att inget att förslagen är helt perfekt och att det är ganska stor skillnad mellan de båda olika rsync-varianterna, vilket till stor del beror på sudo.

Vad som inte syns är att cpio-förslaget lider av ett mer allvarligt problem som gör så att en massa kataloger i kopian får root som ägare, vilket leder till till att man förmodligen inte ens kan logga in efteråt eftersom bland annat ~/.ICEauthority drabbas. Källan till problemet är att find körs med --depth som gör så att katalogerna listas efter alla filer de innehåller istället för innan. Det leder till att cpio måste kopiera filerna till kataloger som inte finns ännu, vilket tydlen löses med -d som ser till att skapa kataloger där det saknas. Men just eftersom vi kör cpio med sudo så kommer alla kataloger som skapas på det sättet att ägas av root. Det hela går att komma runt genom att helt enkelt plocka bort --depth och -d, och då bevarar cpio file owner, member/other group och permission bits; även för katalogerna. Om någon förstår syftet med att använda --depth och -d så är jag tacksam för en förklaring.

Nu är det dags att fundera över vad som kan förbättras. Det är möjligt att cpio- och tar-förslagen kan bli bra mycket bättre med rätt flaggor, men det känns inte helt motiverat att undersöka den saken närmare eftersom de förslagen är onödigt komplicerade redan som det är. Jag väljer istället att koncentrera mig på cp och rsync, och hur man påverkar vad som bevaras med dessa kommandon.

Eftersom vi redan sett att det påverkar ganska mycket om man kör med eller utan sudo så inför jag "sudo" som anger att något endast bevaras om man kör med sudo, men inte annars. Här är resultaten av mina utförliga tester:

cp --sparse=... never always auto
protected files sudo sudo sudo
dense files ok - ok
sparse files - ok ok
directories - - -
block devices - - -
character devices - - -
named pipes - - -
sockets - - -
symbolic links - - -
hard links - - -
file owner - - -
member group - - -
other group - - -
permission bits - - -
access timestamp - - -
modify timestamp - - -
change timestamp - - -
security context - - -
trusted attributes - - -
user attributes - - -
access control lists - - -

cp --preserve=... links ownership mode timestamps context xattr all
protected files sudo sudo sudo sudo sudo sudo sudo
dense files ok ok ok ok ok ok ok
sparse files ok ok ok ok ok ok ok
directories - - - - - - -
block devices - - - - - - -
character devices - - - - - - -
named pipes - - - - - - -
sockets - - - - - - -
symbolic links - - - - - - -
hard links ok - - - - - ok
file owner - sudo - - - - sudo
member group - ok - - - - ok
other group - sudo - - - - sudo
permission bits - - ok - - - ok
access timestamp - - - ok - - ok
modify timestamp - - - ok - - ok
change timestamp - - - - - - -
security context - - - - sudo sudo sudo
trusted attributes - - - - - sudo sudo
user attributes - - - - - ok ok
access control lists - - ok - - ok ok

cp -r -P -d -p -a
protected files sudo sudo sudo sudo sudo
dense files ok ok ok ok ok
sparse files ok ok ok ok ok
directories ok - - - ok
block devices sudo - - - sudo
character devices sudo - - - sudo
named pipes ok - - - ok
sockets ok - - - ok
symbolic links ok ok ok - ok
hard links - - ok - ok
file owner - - - sudo sudo
member group - - - ok ok
other group - - - sudo sudo
permission bits - - - ok ok
access timestamp - - - ok ok
modify timestamp - - - ok ok
change timestamp - - - - -
security context - - - - sudo
trusted attributes - - - - sudo
user attributes - - - - ok
access control lists - - - ok ok

rsync -S -r --devices --specials -D -l -H
protected files sudo sudo sudo sudo sudo sudo sudo
dense files - ok ok ok ok ok ok
sparse files ok - - - - - -
directories - ok - - - - -
block devices - - sudo - sudo - -
character devices - - sudo - sudo - -
named pipes - - - ok ok - -
sockets - - - ok ok - -
symbolic links - - - - - ok -
hard links - - - - - - ok
file owner - - - - - - -
member group - - - - - - -
other group - - - - - - -
permission bits - - - - - - -
access timestamp - - - - - - -
modify timestamp - - - - - - -
change timestamp - - - - - - -
security context - - - - - - -
trusted attributes - - - - - - -
user attributes - - - - - - -
access control lists - - - - - - -

rsync -o -g -p -t -X -A -a -aSHAX
protected files sudo sudo sudo sudo sudo sudo sudo sudo
dense files ok ok ok ok ok ok ok -
sparse files - - - - - - - ok
directories - - - - - - ok ok
block devices - - - - - - sudo sudo
character devices - - - - - - sudo sudo
named pipes - - - - - - ok ok
sockets - - - - - - ok ok
symbolic links - - - - - - ok ok
hard links - - - - - - - ok
file owner sudo - - - - - sudo sudo
member group - ok - - - - ok ok
other group - sudo - - - - sudo sudo
permission bits - - ok - - ok ok ok
access timestamp - - - - - - - -
modify timestamp - - - ok - - ok ok
change timestamp - - - - - - - -
security context - - - - sudo - - sudo
trusted attributes - - - - sudo - - sudo
user attributes - - - - ok - - ok
access control lists - - - - - ok - ok

De bästa varianterna är sudo cp -a och sudo rsync -aSHAX, så det får bli dem vi ställer mot varandra.

Att rsync, till skillnad från cp, där det går gör om dense files till sparse behöver egentligen inte ses som en nackdel. Det kan ju i många fall tvärtom vara en fördel om kopian blir mindre än originalet. Men eftersom det går att ordna motsvarande med cp -a --sparse=always, medan rsync däremot inte kan bevara både dense och sparse files samtidigt så går den första poängen till cp.

Nästa skillnad är att cp -a bevarar access timestamp, vilket rsync -aSHAX inte klarar av; så andra poängen går också den till cp. Å andra sidan så är det sällan man är intresserad av atime om man inte använder mutt eller liknande program.

När det gäller syntax så är cp -a lättare att komma ihåg än rsync -aSHAX, så även den tredje poängen går till cp.

Att kopiera via nätverket är rsync mycket bra på. Det går så klart att montera en nätverksutdelning och låta cp kopiera till monteringen, men vad som fungerar och inte fungerar i det fallet ligger helt utanför vad cp kontrollerar, så denna poäng vinner rsync.

Att kunna återuppta en avbruten kopiering och bara kopiera sådant som inte redan är kopierat är rsync som gjort för. Det finns ett liknande beteende till cp med -u, men det är långt ifrån lika bra, så rsync tar ohotat hem ytterligare en poäng.

Om man av någon anledning vill utesluta saker från kopieringen så fungerar det bra med rsync --exclude=, men det går inte alls med cp, så rsync får därför sin tredje poäng. Det går iofs att komplettera cp med andra verktyg som t.ex. find för att få till samma sak, men det kan lätt bli onödigt knöligt.

Både rsync och cp håller sig inom ett och samma filsystem med -x, och båda visar vad som pågår med -v, så här finns det inga väsentliga skillnader alls.

Sammanfattningsvis så har vi nu dessa två förslag:
Vilket som är bäst får man nog avgöra själv. Tittar man bara på vad som bevaras så vinner cp, men rsync har som bekant flera andra fördelar.

Ojdå, verkligen ett mycket gediget arbete du lagt ned!!
Mycket intressant information som jag givetvis ser till att spara på!

Jag tackar så mycket!!

Konservburks inlägg vinner nog priset bästa inlägg någonsin på detta forumet, snyggt!