Ubuntu Sverige

Har för mig att jag frågat förut, men kunde inte hitta inlägget så jag skapar väl en ny tråd då…

Jag håller på att fippla med mina backup-skript nu igen och har nu gett mig sjutton på att jag inte ska behöva använda sudo för att kopiera mina egna filer, men jag fastnar på en enda fil, eller snarare på en länk.

När jag gör min backup blir det inga som helst problem (utan sudo), utan det är när jag försöker återställa genom att kopiera åt andra hållet, så att säga.

Kommando för att kopiera till min externa hårddisk: EXCLUDE-variabeln innehåller ”--exclude-from /sökväg”, HOME är systemets vanliga, i mitt fall ”/home/guraknugen”. BACKUPFOLDER1 är sökvägen till en mapp på min USB-disk. LOGBACKUP är sökvägen till min loggfil så att jag i efterhand kan se vad som kopierades om jag så vill.

Kommando för att kopiera åt andra hållet: LOGNAME är systemets vanliga, i mitt fall ”guraknugen”. LOGRESTORE är sökvägen till min loggfil så att jag i efterhand kan se vad som kopierades om jag så vill.

När jag kopierar FRÅN USB-disken tillbaka till den interna disken, alltså det senare exemplet, får jag följande felmeddelande: Bla bla bla är i detta fallet sökvägen till en länk. Antog att det var problem med rättigheter, så jag tog en titt på länken som visade sig ha rättigheterna ”rw-r--r--”. Jag har många andra länkar också, men bara denna länken skrek rsync på. Ägare är guraknugen (=jag) och grupp är också guraknugen, precis som när det gäller alla mina andra filer och länkar.

Ett tag funderade jag på om det var för lång sökväg i tecken räknat, men efter en kontrollräkning fann jag att det inte var fler än 97 tecken (totalt med hela sökvägen, 109 tecken för sökvägen till USB-disken) och det borde ju gå bra.

En sak som jag lade märke till är att alla mina andra länkar har rättigheten rwxr-xr-x om länken går till en mapp och att alla mina andra länkar som går till filer har rättigheterna rwxrwxrwx. Så jag ändrade rättigheterna via Nautilus till rwxr-xr-x och körde mitt skript igen, men fick samma felmeddelande. Det märkliga är att rsync verkar ha ändrat tillbaka rättigheterna, för när jag tittar på filen i Nautilus efteråt så är rättigheterna rw-r--r-- igen!

Tidigare har jag löst problemet genom att köra rsync med gksudo -user ${LOGNAME}, men det är det jag vill undvika nu. Att behöva kopiera sina egna filer som root är ju bara trams, tycker jag.

Vad är det nu jag har missuppfattat?
Har googlat lite och ser att många har fått samma felmeddelande, men där verkar man vara inne på att det kan bli så om man kör vfat eller liknande, men det gör inte jag. Jag kör ext3 på allt som är inblandat i detta exempel.

Inte för att jag behöver återställa filer särskilt ofta, men tanken är att synkronisera filer. Med u-flaggan ersätts bara filer med nyare filer, så om jag kopierar först åt ena hållet och sedan tillbaka igen så borde jag få de nyaste filerna på båda ställena. Och det får jag ju också, det är inte det som är problemet, som sagt.

Tips: kolla rättigheterna på filen som länken pekar på? Gör rsync en kopia av symlänken eller av innehållet i själva filen?

Har filen "bla bla bla" grupp "guraknugen" även på backuppdisken?

Jag har några filer med group "games" i min hemmamapp och det lär finnas en fil ".gvfs" med konstiga rättigheter. Om man backar upp eller återställer som user i st f root så får de inte "rätt" group. Inte så allvarligt kanske. Hur som helst har jag experimenterat med att rsynca såna mappar, och symlänkar till såna, men inte lyckats få ditt felmeddelande.

Utanför ämnet: varför har du "-u" ? Och varför inte "--delete" ?

Lars skrev:Tips: kolla rättigheterna på filen som länken pekar på? Gör rsync en kopia av symlänken eller av innehållet i själva filen?

När jag ändrar rättigheterna på länken (i Nautilus) ändras även rättigheterna på originalfilen. Kan det vara så att länkar har egna rättigheter, men att Nautilus bara visar originalfilens rättigheter? En fråga som jag bara kom på just i denna sekund…

Jag använder flaggan -a som är samma sak som -rlptgoD. -l som ingår där betyder ”copy symlinks as symlinks” vilket jag tolkar som att själva länken kopieras. Filen kommer ändå att kopieras, då även den ingår i säkerhetskopian, men den ligger i en annan mapp. Det är därför jag använder länkar, för att vissa filer tycker man passar bra i flera olika mappar samtidigt som man bara vill ha en, annars får man snart ett sammelsurium av filer med samma namn men med olika innehåll…

Det som jag tycker är riktigt konstigt är att, trots att både länken på USB-disken och den på originalstället har exakt samma rättigheter, ägare och datum, så ska rsync dit och pilla. Varför varför varför? Jag använder ju -u-flaggan för att rsync INTE ska bry sig om att ersätta filer om ersättande fil inte är nyare, och det ÄR den ju inte! Mycket konstigt, tycker jag.

David Andersson skrev:Har filen "bla bla bla" grupp "guraknugen" även på backuppdisken?

Exakt samma ägare, samma grupp och samma datum, varför rsync egentligen inte borde röra filen över huvud taget, i och med att jag har -u-flaggan med!

David Andersson skrev:Jag har några filer med group "games" i min hemmamapp och det lär finnas en fil ".gvfs" med konstiga rättigheter. Om man backar upp eller återställer som user i st f root så får de inte "rätt" group. Inte så allvarligt kanske. Hur som helst har jag experimenterat med att rsynca såna mappar, och symlänkar till såna, men inte lyckats få ditt felmeddelande.

Jo, jag börjar misströsta. Funderar på om jag ska använda cp istället… Detta enkla kommando kan också göra exakt det som jag är ute efter, med nästan samma flaggor dessutom… Det var dock något annat skumt med den, men det går att komma runt med en enkel if-sats i skriptet.

David Andersson skrev:Utanför ämnet: varför har du "-u" ? Och varför inte "--delete" ?

-u = ”skip files that are newer on the receiver”. Anledningen är just den. Min USB-disk använder jag med två olika datorer. Filerna på den ena, en Eee-PC, är delvis desamma som på min ”riktiga” bärbara, låt oss i fortsättningen kalla den för PB (som i Packard Bell). När jag gör backup med min Eee, hamnar filerna på två ställen: Dels i USB-diskens (i forsättningen kallad USBd) Eee-mapp och dels på vederbörliga ställen i några undermappar till backupmappen för min PB. När jag gör en säkerhetskopia från PB till USBd vill jag inte att filer där som är nyare än de i min PB ska skrivas över, för de filerna kommer från Eee. Vad jag istället gör, är att jag först gör en säkerhetskopia av min Eee. Därefter kopplar jag in USBd till PB, gör säkerhetskopia och återställer. Återställningen gör att de filer jag nyligen ändrat i Eee hamnar i rätt version på PB. Därefter kopplas USBd åter till Eee, där en återställning görs. Detta gör att jag får de senaste filerna på både PB och Eee. Dock ser skripten givetvis olika ut på PB och Eee eftersom innehållet på Eee bara är en delmängd av innehållet på PB.

Allt detta "krångel" bara för att jag inte har något nätverk, annars hade jag ju bara gjort ett skript som gör en säkerhetskopia av en delmängd av innehållet på PB till Eee och därefter en återställning av samma typ. Vips så hade det problemet varit löst i ett musklick. Men jag har inte orkat ta tag i det där med nätverk. Har en trådlös router som jag inte använt på flera år, och det beror mest på att den inte fungerade så bra. Tappade kontakten hela tiden.

Att jag inte använder --delete beror på att det kan strula till det om det kommit in en extra fil i en "målmapp". Då kommer ju den att tas bort av rsync och det kanske jag inte vill. Däremot kör jag min egen variant av detta, men den tar tid då den innebär en total backup till en tom mapp, nämligen så här:
Jag har två mappar (bland andra, men som är relevanta i detta sammanhang) på USBd: PB1 och PB2. När jag vill ha samma innehåll gör skriptet bara så att det raderar PB2, byter namn på PB1 till PB2, skapar en ny PB1 och gör sedan en vanlig säkerhetskopia till PB1. Då får jag exakt samma innehåll (bortsett från att jag låter rsync strunta i vissa mappar) och har dessutom kvar den gamla säkerhetskopian, ifall jag kommer på att det var dumt gjort och vill ånga mig. Själva ångrandet har jag dock inte lagt in i skriptet, utan det får jag i så fall göra manuellt.

Egentligen skulle jag vilja skriva ett helt eget program i C++ som gör hela jobbet, för de program som jag sett hittills, typ rsync, fungerar aldrig som jag vill. Det finns en massa flaggor som är totalt meningslösa för just mig och de som jag egentligen vill ha fungerar bara UNGEFÄR som jag skulle vilja. Dock verkar alla andra ha helt andra behov, så om jag gjorde ett sådant program, som för övrigt säkert inte skulle bli speciellt bra heller, då mina C++-kunskaper inte är så uppdaterade som jag skulle önska, så skulle förmodligen ingen annan än jag ha någon som helst nytta av det…

Problemet är nu löst. Så här ligger det tydligen till, om någon annan vill veta:

När man beskådar en länk i Nautilus och har ställt in den på att visa ägare, grupp och rättigheter, så visas denna information för FILEN som länken pekar på, INTE för själva länken. Det är detta faktum som förbryllade mig. När jag tittade på länkarna i en virtuell terminal istället, såg det annorlunda ut:
Originalfilen: Länken på USB-disken: Länken på den interna hårddisken, som befinner sig i en annan mapp än originalfilen: Som alla nu kan se, så var det precis så som vissa här redan misstänkte från början: Länken i målmappen ägs av root, inte av mig. Då jag inte har något som helst behov av att låta root äga mina filer, blev lösningen enkel: -h ser till att länken ändras och inte målfilen, som det annars hade blivit.

Tack för allt engagemang!

Och lita ALDRIG på Nautilus…! ☺

Funderar fortfarande lite på varför rsync skulle ge sig på länken över huvud taget, då dess tidsstämpel är identisk för båda länkarna. Kan det bero på att originalfilen har ett senare datum än länkarna?