copy ne másoljon symlink mappát

Linux-kezdő

sziasztok!

banális dologgal szembesülve (nyilván valamiért nem látom a fától az erdőt) nem találok jó megoldást. van egy könyvtárstuktúrám amiben van egy olyan almappa is, ami csak egy symlink egy másik (az egész kupacon kívül levő) mappára.

azt szeretném, hogy ha másolom a kérdéses mappákat, akkor a symlink (és vele a tartalma) ne menjen. azt hittem, hogy a cp parancs jó lesz nekem a következőképpen paraméterezve:

cp -Pr forrás cél

ettől függetlenül a forráson belül levő symlink mappa tartalmastul ment vele. biztos triviális a megoldás, de valamiért nem jövök rá. tudtok segíteni? :)

kiegészítés, mivel voltak félreértések: a hatása a kívánt parancsnak az legyen, mint mondjuk a következőnek:

rsync -r --safe-links forrás cél

  • 1592 megtekintés

( lx | 2009. 08. 19., sze – 18:24 )

Ja, elég triviális: nem ment vele semmi. A symlink alatt ui. nincs semmi, mivel - ahogy a neve is mutatja - az csak egy link, ami oda mutat, ami alatt viszont van valamilyen tartalom, na azt a tartalmat látod a másolt helyen, és nem annak a tartalomnak valamiféle másolatát.

Teendő: semmi.

meglehet pontatlanul fogalmaztam meg mit szeretnék és ezért vezettelek félre. legyen az alábbi struktúra: 

/krumpli/
  uj
  regi
/forrás/
  alma
  korte
  /burgonya    <- ez itt a symlink a /krumpli/-ra 
    uj
    regi
/cél/

a /burgonya/ mappa egy symlink a fentebbi /krumpli/ mappára. azt szeretném elérni, hogy a /cél/ mappában létrejöjjön a következő struktúra:

/cél/
  alma
  korte
  /burgonya

magyarán ne másolódjon a tartalma. a "cp -Pr" parancs viszi a tartalmat is. ezt akarom elkerülni. így is ugyan azt mondod válasznak?

--
xterm

Maximálisan.


find krumpli -ls
613906 4 drwxrwxr-x 2 lx lx 4096 Aug 19 18:50 krumpli
find forras -ls
613907 4 drwxrwxr-x 4 lx lx 4096 Aug 19 18:49 forras
1297452 0 lrwxrwxrwx 1 lx lx 10 Aug 19 18:49 forras/burgonya -> ../krumpli
613909 4 drwxrwxr-x 2 lx lx 4096 Aug 19 18:49 forras/korte
613908 4 drwxrwxr-x 2 lx lx 4096 Aug 19 18:49 forras/alma
cp -Pr forras cel
find cel -ls
613910 4 drwxrwxr-x 4 lx lx 4096 Aug 19 18:53 cel
1737940 0 lrwxrwxrwx 1 lx lx 10 Aug 19 18:53 cel/burgonya -> ../krumpli
613911 4 drwxrwxr-x 2 lx lx 4096 Aug 19 18:53 cel/korte
613912 4 drwxrwxr-x 2 lx lx 4096 Aug 19 18:53 cel/alma

Látszik, hogy a cel/burgonya semmi egyéb, mint symlink ugyanúgy, ahogy a forras/burgonya volt. És akkor is az, ha a krumpli tele van mindenféle kacattal.

először is köszi, hogy próbálsz segíteni! másodszor, valami nem kerek nálam. ha a krumpli mappa tele van kacatokkal, akkor a cél mappámban levő "másolata" is tele lesz. pont azt akarom, hogy ott ne legyen semmi (akár olyan áron is, hogy maga a symlink nem is másolódik).

hogy tisztább legyen: van egy mappa, amiben sok mindent tartok, de az esetek egy részében minden file-t akarok másolni, egy más részében meg csak egy "csökkentett" részét. ezért csináltam a symlinket. viszont így valamiért "mindig ott figyel" az egész, nem tudom elkerülni... :( már azon vagyok, hogy a cp helyett valami scripttel másoljam (pl. listázok rekurzívan, és soronként nézem, hogy symlink-e és ha nem, akkor másolom... de ez baromi beteg megoldás...)

--
xterm

Fizikailag _nincs_ott_semmi_, mint ahogyan hup.hu sincs a gépemen, csak azért, mert a firefox bookmark.html-je tartalmazza a http://hup.hu url-t, amely url funkciójában tök ugyanaz, mint a symlink.

De ha annyira zavaró a link létezése, másolás után ki lehet fésülni:

find cel -type l -exec rm {} \;

hm... azt hittem megfogalmazni könnyebb, de jelek szerint több, mint nehéz. akkor még részletesebben :D bocs!

van egy mappa, amiben gyüjtök állományokat. ezt néha részben, néha egészben másolom egy másik diszkre. amikor nem kell az egész, akkor csak a "magját" másolnám. ezért a mappába belinkeltem a kiegészítő tartalmat. úgy akartam másolni, hogy a a symlinkkel "odarakott" tartalom a másik diszken ne legyen. egy sima cp -Pr eredménye mégis az lett, hogy bizony ott lettek a linkelt tartalmak is. a hely és az idő kritikussága miatt nem akarok pl. 20k helyett 200 megát másolni, csak ha feltétlen kell. így se érthető? :)

emiatt nem tehetem meg, hogy utólag kozmetikázom a másolatot, hiszen akkor már átment a felesleges tartalom, sávszélt, időt, stb elzabálva.

--
xterm

Szerintem marhára nem érted mi is a symlink.
A symlink olynan file amiben csak egy path van. Attól hogy átmásolja nem lesz 20k helyett 200 mega, hacsak nincs legalább 200 ezer symlinked (blokkmérettől függ). Attól hogy a symlink megjelenik az új helyen attól még a könyvtár amire a symlink mutat (../burgonya a példában) az nem másolódik át (hacsak nem használtad a -H kapcsolót).

kezdtem én is azt hinni, amit mondasz, de akkor mi magyarázza meg azt, hogy a "cél" nem 20k, hanem 200 mega? sőt, megtoldom még valamivel. a cél olyan filerendszerre is átkerült, ami a symlink típust fel se fogja, akkor is ez a szitu. meglehet, hogy valamit nem értek, de az nem a symlink fogalma ;) (hiszen akkor már az elején nem is létezett volna a probléma, hiszen nem másolódott volna át annyi file, mint amennyi, hanem csak a töredéke). bár olyan egyszerű lenne, hogy "marhára nem érted" :)

--
xterm

egy ideig én is azt hittem (mivel egy pxeboot-os gép "hozott anyagból dolgozva" emészt meg egy scriptben levő cp parancsot; tehát először simán azt hittem, hogy csak annyi a gond, hogy az a cp nem érti a P paramétert). aztán egy másik gépen (lévén ott legalább nem kellett végigvárnom a kísérletek miatt a teljes boot folyamatot minden szarságával együtt!), vagyis egy distro (ubuntu, mivel nem volt más kéznél) más-más gépein gyártottam egy teszt környezetet és ott duhajkodtam ezzel a feladattal. sajna még eredménytelenül (és közben még azt is megkaptam, hogy szimplán marhára nem értem mi az a symlink és higyjem el, hogy az átmásolt 100 megák ott sincsenek :D).

két aliasom van csak:

$ alias
alias ll='ls -l'
alias ls='ls --color=auto'

$which cp
/bin/cp

kezdem azt hinni, hogy a cp nem jó megoldás erre a feladatra. de most vagy gyártok egy scriptet, ami végigmazsolázza a filerendszert és a symlink mappákba nem is megy bele, vagy pedig más eszköz után nézek.

elképzelhető lenne, hogy mind az ubi, mind a pxeboottal behúzott image egyaránt "herélt" cp-t tartalmazna?? a manualban ott a paraméter és szarik rá?? bár lehet, de eddig ezzel kapcsolatban nem is nyomoztam, hiszen ha két független linux disztrib is azonos jelenséget produkált, honnan is sejtettem volna ezt...

ja, a kérdésre a válasz: a végleges, tehát amiért elkezdtem, az fat32.

--
xterm

a symlinket hogy hoztad létre? "teljes útvonallal", vagy csak relatív útvonallal? mert ugyan beteg megoldás, de eszembe jutott még valami. ha relatív útvonallal hozom létre a filet, nem pedig /-tól, akkor ugye a másolás után a példa szerinti esetben a link elbaxódik. következésképpen "nem követhető". így "működik", maga a másolat létrehozása. egyetlen problémám (viszont ezt csak köv munkanapon tudom kipróbálni), hogy vajon a többi script megeszi-e így a végeredményt (valami azt súgja, hogy nem, ha már ennyit szoptam vele...).

--
xterm

A symlinket teljes útvonallal hoztam létre, és nálam teljesen normálisan működött.

Tehát ha volt egy symlinkem ami egy 2 gigás könyvtárra mutatott és átmásoltam "cp -r"-el akkor az új könyvtárban is symlink lett. Nem másolta át a 2 gigát csak ha "cp -H" val kezdtem másolni.

kiegészítés n+1 :)

fogd fel úgy, hogy van az eredeti példában levő symlink egy mappa, amibe bind-dal "fel van csatolva" egy másik mappa. innentől az lenne a dolgom, hogyha mindent másolni akarok, akkor sima cp -r, ha meg nem, akkor "unbindolom", majd _aztán_ sima cp -r. ez működne is, csak van egy kis gond. nem egyetlen process létezik a rendszerben, ami a mappát piszkálja, ergo vagy nem tudnám kirántani alóla a mappát, vagy pedig ha épp sikerülne, akkor halna meg pár process, mert nem találja ott amit keres.

(egy dolgot viszont lehet meg tudsz világítani: pontosan mi a különbség a -H és a -L között?)

--
xterm

( mzperx | 2009. 08. 19., sze – 19:33 )

cp -Prl forras cel ?! Tehát + "-l" kapcsoló.

Ati

azért nem jó megoldás, mert ha egy másik script épp akkor dolgozna a symlinkben levőkkel, amikor törölve van, akkor az elhasal. eddig egy tippet kaptam még, ami bejöhet, csak nem akarózik, csak végső megoldásként. ez pedig az, hogy másik filerendszerre mutasson a symlink és akkor a cp parancs talán végrehajtja azt, hogy "maradjon egy filerendszeren". nem próbáltam még, de abból kiindulva, hogy a -P paramétert se úgy hajtja végre, mint ahogy a man-ban van leírva... legalábbis kétséges a végkifejlet... brute force megoldásként tartogatom azt, hogy egy scripttel kopizgatom a mappákat egyetlen parancs helyett... de ez azért gusztustalan, mert ha javítani kell, vagy bővül, vagy akármi, akkor túl sok helyen kell módosítani... és fejben tartani, hogy hol kell még módosítani. :/

--
xterm

( ironcat | 2009. 08. 22., szo – 11:31 )

Nálam is tökéletesen működik. Sőt nálam még a -P sem kötelező, mert alapértelmezésben csak a linket másolja át.

A kimenetem:
xxxxx@xxxxx:~/proba$ ls -l ./*
./forrás:
összesen 36
-rw-r--r-- 1 xxxxx xxxxx 10245 2008-06-18 15:42 alma
lrwxrwxrwx 1 xxxxx xxxxx 26 2009-08-22 11:02 burgonya -> /home/xxxxx/proba/krumpli/
-rw-r--r-- 1 xxxxx xxxxx 22422 2008-06-18 15:38 korte

./krumpli:
összesen 352
-rw-r--r-- 1 xxxxx xxxxx 331268 2009-08-15 18:07 regi
-rw------- 1 xxxxx xxxxx 25441 2009-02-06 03:20 uj
xxxxx@xxxxx:~/proba$ du -h
40K ./forrás
356K ./krumpli
400K .
xxxxx@xxxxx:~/proba$ cp -Pr forrás /media/disk/linux/cél
xxxxx@xxxxx:~/proba$ du -h /media/disk/linux/cél
40K /media/disk/linux/cél/forrás
44K /media/disk/linux/cél
xxxxx@xxxxx:~/proba$ ls -l /media/disk/linux/cél/*
összesen 36
-rw-r--r-- 1 xxxxx xxxxx 10245 2009-08-22 11:19 alma
lrwxrwxrwx 1 xxxxx xxxxx 26 2009-08-22 11:19 burgonya -> /home/xxxxx/proba/krumpli/
-rw-r--r-- 1 xxxxx xxxxx 22422 2009-08-22 11:19 korte
xxxxx@xxxxx:~/proba$

A du -h kimenetéből látszik, hogy a burgonya szimbolikus link alatti fájlok nem másolódtak át. A link miatt viszont elérhetőek a krumpli könyvtárban lévő fájlok, bár fizikailag nem másolodtak át.

Melyik disztribució alatt probáltad? Mi a cp --version kimenete? Esetleg próbáld meg úgy, hogy az elérési utat is beírod: /bin/cp -Pr ........ A /bin/cp fájl nem egy link? Esetleg egy szkript?
Esetleg a fenti parancsokat (az útvonalak korrigálásával) lefuttathatnád, és a kimenetet bemásolhatnád.

$cp --version
cp (GNU coreutils) 6.10
Copyright (C) 2008 Free Software Foundation, Inc.
A licenc GPLv3+: a GNU GPL 3. vagy újabb változata
Ez egy szabad szoftver, terjesztheti és/vagy módosíthatja.
NINCS GARANCIA, a törvény által engedélyezett mértékig.

$which cp
/bin/cp

$file cp
cp (GNU coreutils) 6.10
Copyright (C) 2008 Free Software Foundation, Inc.
A licenc GPLv3+: a GNU GPL 3. vagy újabb változata
Ez egy szabad szoftver, terjesztheti és/vagy módosíthatja.
NINCS GARANCIA, a törvény által engedélyezett mértékig.

a file-ok másolódnak sajna (bár lényegesen parasztosabb módon derült ki :) hiszen egy másik rendszer alá kerültek a file-ok és meglepve láttam, hogy mit keresnek ott (más os alá csak nem kéne működjön egy hálózaton "túl" levő symlink... :) (ki tudnád próbálni olyan filerendszeren, ami nem érti a linket? mert ugye nekem vfat a végcél, hiszen a link teljes útvonallal létrehozva szükség szerint "láttatná" a linkelt tartalmat. amit viszont én akarok az meg az, hogy a vfat-ra ne másolódjon át semmi, ami link mögött van. és mégis megtette. (rsync simán kikerüli a symlinket, ha kérem és nem is másolja át)

--
xterm

Ha vfat-ra akarom másolni:
cp: "/media/1GByte/cél/forrás/burgonya" szimbolikus link nem hozható létre: A művelet nem engedett

A többit átmásolja, tehát pont úgy működik, ahogy szeretnéd:
xxxxx@xxxxx:/media/1GByte$ du -h cél
40K cél/forrás
44K cél

Én is Ubuntu (9.04) alatt próbáltam.

( hrgy84 | 2009. 08. 22., szo – 11:47 )

Elolvasva a topicot: cp -a /forras /cel
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

( mchalls | 2009. 08. 23., v – 07:26 )

Nincs a cp-d aliasolva valamire alapbol ami miatt azt hisszuk hogy a /bin/cp fut, holott esetleg van egy plusz kapcsolo aliasban.... ? :-)

Az 'alias' mit ir ki ? :o)

Es mar latom is hogy volt errol szo, bocsesz :-D
Viszont sokat segitene sztem ha leirnad egy mini peldan az OSSZES lepest amit csinalsz, a legelejetol addig hogy megnezed mi van a konyvtarban ami symlinkes. Valszeg vmi banalis dolog lesz, de igy csak tippelgetni lehet (bar nagyjabol mindent vegig tippeltek mar az elozoekben szolok).

Most mar kivancsi vagyok mi lesz a kimenet :-)

( Lory | 2009. 08. 23., v – 08:55 )

Sajnos tényleg nem tudom mi a hiba

Nálam otthon (Gentoo alatt) műxik.
Munkahelyemen (Debian):

$ mkdir test1
$ mkdir test2
$ cd test1
$ ln -s /store/Nagy\ fajlokkal\ Teli\ Konyvtar/ TEST
$ ls
TEST
$ cd ../test2
$ cp ../test1/* ./
cp: omitting directory `../test1/TP'
$ cp -r ../test1/* ./
$ ls
TEST
$ cd ../test1/
$ ln -s /store/Masik\ nagy\ fileokkal\ teli\ konyvtar/ ./ize/
ln: target `./ize/' is not a directory: No such file or directory
$ ln -s /store/Masik\ nagy\ fileokkal\ teli\ konyvtar/ ./ize
$ ls
TEST ize
$ ln -s /store/Masik\ nagy\ fileokkal\ teli\ konyvtar ./ize2
$ ls
TEST ize ize2
$ cd ../test2/
$ ls
TEST
$ cp -r /ut\ a\ test1-hez/test1/* /ut\ a\ test2-hoz/test2/
$ ls
TEST ize ize2
$ cp --version
cp (GNU coreutils) 6.10
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Torbjorn Granlund, David MacKenzie, and Jim Meyering.

Tehát nálam működik.
Milyen fájlrendszer(eket) használsz? Hátha ott van valami implementációs bibi.

Megj: az "ln -s /ut/konyvtar/ ./nev"-hez bashcomp kell. (a helyes alak "ln -s /ut/konyvtar ./nev")

Megj: az "ln -s /ut/konyvtar/ ./nev"-hez bashcomp kell. (a helyes alak "ln -s /ut/konyvtar ./nev")

????????????
NEM kell bashcomp. Mindket alak mukodokepes, de egyebkent is, a bashcomp-nak az egvilagon semmi hatasa nincs az ln parametereire. Nem tudom hol olvastad ezt az okorseget, de elfelejteni. Most.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

( Xterm v | 2009. 08. 23., v – 12:36 )

nagyon szépen köszönöm a sok segítőkész embernek a próbálkozást. azt hiszem egy időre jegelem a dolog megfejtését és egy scriptet gyártok a probléma kikerülésére. azt hiszem a fentiekből talán látszik, hogy megpróbáltuk sokféleképpen és ennek ellenére nem sikerült megfejteni a hiba okát. átmenetileg feladtam (a végeredményt jelentősen hátráltatja már ez az "egysoros" probléma :) és így nem haladok semerre). mindenkinek kösz a közreműködést!

--
xterm