Hi!

Gibt es eine einfache Möglichkeit beim Kopieren von Verzeichnissen Hardlinks zu erhalten?
Mir ist bekannt dass cp dazu nicht in der Lage ist und rsync sowohl zu aufwendig (lokale Kopie) als auch - mitunter - gefährlich.
cp(1) empfiehlt pax oder tar für solche Aufgaben, doch irgenwie will es nicht:

Code :

1	$ pax -rwl /source /destination

... zum Beispiel linkt alle Dateien in /source, nicht nur diejenigen welche schon Links sind.
Klar könnt' ich jetzt ein Skript schreiben das die Aufgabe übernimmt, doch ich bin sicher dass es sowas schon gibt.
Nur kann ich es einfach nicht finden. Steh ich auf dem Schlauch?
Bin dankbar für jede Hilfe!

Gruß
Enum

Hi.

Also "cp -a" kopiert auch Hardlinks. Oder was genau meinst du?

Gruß

Das Kopieren von Archiven ist eine GNU-Erweiterung und nicht im IEEE Std 1003.1-2008 enthalten.
Leider habe ich dieses Feature auf den betreffenden Systemen (OpenBSD und Solaris) nicht.

Zitat von Enumerator

Das Kopieren von Archiven ist eine GNU-Erweiterung und nicht im IEEE Std 1003.1-2008 enthalten.
Leider habe ich dieses Feature auf den betreffenden Systemen (OpenBSD und Solaris) nicht.

Ah, verstehe. Dann sollte doch aber "pax -rw" das sein was du möchtest, oder?

Gruß

Irgendwie nicht; es passiert so ziemlich das gleiche wie mit cp -r:

Code :

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

$ mkdir skel test $ touch skel/1 skel/2 $ ln skel/2 test/ $ ls -la skel/ total 8 drwxr-xr-x  2 enum  users  512 Apr 27 13:03 . drwxr-xr-x  5 enum  users  512 Apr 27 13:04 .. -rw-r--r--  1 enum  users    0 Apr 27 13:03 1 -rw-r--r--  2 enum  users    0 Apr 27 13:03 2 $ ls -la test/ total 8 drwxr-xr-x  2 enum  users  512 Apr 27 13:04 . drwxr-xr-x  5 enum  users  512 Apr 27 13:04 .. -rw-r--r--  2 enum  users    0 Apr 27 13:03 2 $ pax -rw skel/ test/ $ ls -la test/skel/ total 8 drwxr-xr-x  2 enum  users  512 Apr 27 13:03 . drwxr-xr-x  3 enum  users  512 Apr 27 13:04 .. -rw-r--r--  1 enum  users    0 Apr 27 13:03 1 -rw-r--r--  1 enum  users    0 Apr 27 13:03 2 $

Zitat von Enumerator

Irgendwie nicht; es passiert so ziemlich das gleiche wie mit cp -r

Ah, jetzt seh ich was du meinst.

Die Tools wie pax bzw. tar oder cpio werden da nicht helfen, denn die haben nur die Informationen aus dem jeweiligen Archiv und stellen dementsprechend die Links laut den Informationen im Archiv wieder her. Wenn die entsprechend verlinkte Datei nicht im Archiv drin ist, kann sie auch nicht wieder verlinkt werden (sie wird ja auch gar nicht ausgepackt).

Das funktioniert:

Code bash:

1 2 3 4 5 6 7 8

$ mkdir skel test $ touch skel/1 skel/2 $ ln skel/2 skel/copy $ pax -rw skel/ test/ $ ls -l test/skel -rw-r--r-- 1 root root 0 2010-04-27 13:36 1 -rw-r--r-- 2 root root 0 2010-04-27 13:36 2 -rw-r--r-- 2 root root 0 2010-04-27 13:36 copy

Warum willst du denn überhaupt für Dateien mit mehr als einem Link einen weiteren Link hinzufügen, für andere Dateien aber nicht? Dann kannst du doch gleich alles verlinken (pax -rwl), oder?

Gruß

Zitat von deepthroat

Die Tools wie pax bzw. tar oder cpio werden da nicht helfen, denn die haben nur die Informationen aus dem jeweiligen Archiv und stellen dementsprechend die Links laut den Informationen im Archiv wieder her. Wenn die entsprechend verlinkte Datei nicht im Archiv drin ist, kann sie auch nicht wieder verlinkt werden (sie wird ja auch gar nicht ausgepackt).

Aha - jetzt ist alles klar. Danke für die Aufklärung!

Zitat von deepthroat

Warum willst du denn überhaupt für Dateien mit mehr als einem Link einen weiteren Link hinzufügen, für andere Dateien aber nicht? Dann kannst du doch gleich alles verlinken (pax -rwl), oder?

Mir fiel das Problem auf als ich diverse skeletons für Entwicklungs-Ordner machen wollte.
Da ich so ziemlich alle - kleine, private wie größere - Coding-Arbeiten mit git verwalte, brauchen diese Ordner auch eine .gitignore Datei - und die hätt' ich gern einheitlich (in den Kopien, nicht den Vorlagen).
Allerdings hat git (zumindest in den Versionen die Ich benutze) diverse Probleme mit Symlinks für .gitignore und .gitconfig - entweder sie werden rotzfrech durch eine Kopie der verlinkten Datei ersetzt oder gar nicht erst gefunden.
Daher war ich gezwungen auf Hardlinks zurückzugreifen.

[PS]
Die erste Zeile in jeder .gitignore ist ".gitignore".
Ganz so dämlich bin ich ja auch nicht...

Zitat von Enumerator

Mir fiel das Problem auf als ich diverse skeletons für Entwicklungs-Ordner machen wollte.
Da ich so ziemlich alle - kleine, private wie größere - Coding-Arbeiten mit git verwalte, brauchen diese Ordner auch eine .gitignore Datei - und die hätt' ich gern einheitlich (in den Kopien, nicht den Vorlagen).

Das geht dann aber schonmal gar nicht (automatisch). Du müßtest ja eine einzelne (nicht ge-hart-linkte) .gitignore Datei in der Vorlage haben die du dann beim Kopieren zu den bereits vorhandenen Projekten verlinkst.

Zitat von Enumerator

[PS]
Die erste Zeile in jeder .gitignore ist ".gitignore".
Ganz so dämlich bin ich ja auch nicht...

Also bei mir sind die ignore Dateien (sei es bei Git oder Mercurial) immer mit versioniert. Jedes Projekt bekommt (logischerweise) dann eine eigene ignore Datei.

Gruß

Zitat von deepthroat

Das geht dann aber schonmal gar nicht (automatisch). Du müßtest ja eine einzelne (nicht ge-hart-linkte) .gitignore Datei in der Vorlage haben die du dann beim Kopieren zu den bereits vorhandenen Projekten verlinkst.

Ich vergaß zu erwähnen das die Datei einen Backup-Hardlink hat.

Zitat von deepthroat

Also bei mir sind die ignore Dateien (sei es bei Git oder Mercurial) immer mit versioniert. Jedes Projekt bekommt (logischerweise) dann eine eigene ignore Datei.

Die Projekte auf die ich den skel anwenden will enthalten überlicherweise keine Dateien die wirklich ignoriert werden sollen, und wenn dann nicht im Projekt-root. In der .gitignore unter skel/c stehen Einträge wie z.B. "*.core" (automatisch generierte Core-Dumps / OpenBSD), "build" (der name des Build-Directories wie ich ihn verwende, andere im selben Projekt haben eigene Präferenzen), ".vimsession", ".tags" etc. Also dient die Datei in erster Linie dazu die Commits nicht zu verschmutzen.
Ich verwende auch gern ein eigenes Makefile im Projekt-root (das zum Builden haut CMake nach build) das mir projektspezifische wie auch persönliche aufgaben erleichtert. So hab' ich z.B. ein kleines skript nach /usr/local/bin/rmk verlinkt, das automatisch den Projekt-root findet, in das Verzeichnis wechselt und dort seine Parameter an make weiterreicht. Damit ist es überall in der Hierachie möglich z.B. ein "rmk && rmk test" zu tippen oder "rmk backup" etc.
Dieses Makefile ist natürlich auch in der .gitignore aufgeführt.

Wie Du siehst hab' ich da schon meine Eigenheiten (die sich natürlich auch hin und wieder ändern, z.B. wenn ich dank eines gewissen Jemand mit anstößigem Pseudonym mal eben das Build-System wechsle.. ).
Die von Dir zitierte Aussage im PostSkriptum bezog sich auf die Tatsache dass ich Probleme mit git und Symlinks hatte.

Im Übrigen habe ich jetzt kurzerhand ein Skript geschrieben das so kopiert wie ich das gern hätte.

Gruß
Enum

Zitat von Enumerator

Wie Du siehst hab' ich da schon meine Eigenheiten (die sich natürlich auch hin und wieder ändern, z.B. wenn ich dank eines gewissen Jemand mit anstößigem Pseudonym mal eben das Build-System wechsle.. ).

Wen meinst du, wen meinst du... ? *aufgeregt* *hopp* *hopp*

Gruß

Das weißt du ganz genau, der "... ist berühmt wie kein Zweiter".