# cp ändert Dateidatum

## rblock

Hallo,

irgendwie bin ich etwas verwirrt, denn mir ist gerade aufgefallen, dass, kopiere ich eine Datei über die Konsole per "cp", wird das aktuelle Datum als Datum einer Änderung eingetragen. Kopiere ich eine Datei per Konqueror oder Krusader, wird das Änderungsdatum nicht angefasst. Allerdings war das früher nicht so und ich weiß nicht seit wann dies der Fall ist.  :Shocked: 

Kann mir jemand verraten woher das schon wieder kommt? Ich habe weder hier im Forum noch woanders Hinweise dazu gefunden.  :Rolling Eyes: 

Verwirrte Grüße

----------

## zouk

 *rblock wrote:*   

> Kann mir jemand verraten woher das schon wieder kommt? Ich habe weder hier im Forum noch woanders Hinweise dazu gefunden. 

 

Wo hast du denn nach Hinweisen gesucht?

google

man cp

gruß

zouk

p.s. cp -a xyz zyx erhält z.b. auch das Datum

----------

## rblock

<ironie an>Danke für die ausführliche Antwort.</ironie>

Also das habe ich schon versucht. Abgesehen davon das Google, sucht man über englischsprachige Seiten, mehr als 47.000 Treffer findet wenn man nach den Stichworten "linux cp copy changes file date" sucht. Nimmt man "updates" statt "change" kommt man auf über 24.000 Seiten. Schränkt man die Suche mit "-suse -mv" weiter ein, kommt man immer noch auf fast 14.000 Seiten.  :Sad: 

Es ist aber nun mal so, dass ein "cp" grundsätzlich das original Dateidatum übernimmt und es nicht ändert. Warum also wird es plötzlich geändert? Und das nur auf der Kommandozeile? Einen entsprechenden Alias habe ich nicht eingerichtet.

Nachdenkliche Grüße

----------

## grantangi

 *rblock wrote:*   

> 
> 
> Es ist aber nun mal so, dass ein "cp" grundsätzlich das original Dateidatum übernimmt und es nicht ändert. Warum also wird es plötzlich geändert? Und das nur auf der Kommandozeile? Einen entsprechenden Alias habe ich nicht eingerichtet.

 

Verwechselst du da nicht etwas  :Question: 

"cp" nimmt immer das aktuelle Datum fuer die neue Datei im Gegensatz zu "mv"...welcher das Datum der Ursprungsdatei uebernimmt. Du kannst allerdings mit "cp -p" die Attribute der Ursprungsdatei auf die Kopie uebernehmen.

  See ya

     Udo

----------

## ralph

 *rblock wrote:*   

> 
> 
> Es ist aber nun mal so, dass ein "cp" grundsätzlich das original Dateidatum übernimmt und es nicht ändert. Warum also wird es plötzlich geändert? Und das nur auf der Kommandozeile? Einen entsprechenden Alias habe ich nicht eingerichtet.
> 
> Nachdenkliche Grüße

 

1. Warum so unfreundlich zum vorherigen Poster?

2. Scheint das, was du behautptest, schlicht nicht der Fall zu sein, wie ein Blick in die man page verraten sollte:

 *Quote:*   

>  --preserve=ATTRIBUTES (since file-utils 4.1)
> 
>               Here  ATTRIBUTES can be one of "mode" (permissions), "ownership"
> 
>               (owner and group), "timestamps",  "links",  "all"  (all  of  the
> ...

 

Die Option wäre ja ziemlich überflüssig, wenn es ohnehin das normale Verhalten wäre, oder?

----------

## rblock

Da diese Vorgehensweise für mich unverständlich ist, denn eine Kopie, bzw. man kann es ja in diesem Fall auch Klon nennen, sollte die gleichen... Ach nein, ich höre besser auf, denn das endet in einer Grundsatzdiskussion...  :Wink: 

Ich habe mir nun einen Alias erstellt, der den Parameter "-p" enthält; Und nun sind die Kopien IMHO o.k.  :Smile: 

Zwinkernde Grüße

----------

## Earthwings

ralph hat schon recht, standardmäßig werden die timestamps der alten Datei nicht übernommen. Das kann natürlich in einer früherern Version von cp anders gewesen sein.

 *coreutils/cp.c wrote:*   

> 
> 
> 876-    case 'a':               /* Like -dpPR. */
> 
> 877-      x.dereference = DEREF_NEVER;
> ...

 

konqueror arbeitet unabhängig von cp und co., hier scheint standardmäßig der timestamp übernommen zu werden, siehe hier ab Zeile 02312. Ich habs zwar nicht bis konqueror zurückverfolgt, aber das dürfte verwendet werden.

Meiner Meinung nach hat beides seine Berechtigung. Beim Kopieren wird eine neue inode erzeugt, und da sie unmittelbar beim Kopieren erzeugt wurde, sollte sie keinen Zeitstempel aus der Vergangenheit besitzen. Auf der anderen Seite entspricht das Übernehmen der alten Zeitstempel eher der naiven Erwartung einer 1:1 Kopie.

konqueror übernimmt übrigens nicht alle alten Zeitstempel, die "status change" time wird auf die aktuelle Zeit gesetzt. Kannst Du mit "ls -lc <datei>" überprüfen.

----------

## toskala

 *rblock wrote:*   

> Da diese Vorgehensweise für mich unverständlich ist, denn eine Kopie, bzw. man kann es ja in diesem Fall auch Klon nennen, sollte die gleichen... Ach nein, ich höre besser auf, denn das endet in einer Grundsatzdiskussion...  

 

ich verstehe dich nicht.

eine kopie einer datei ist nicht das klonen einer datei. die kopie ist ein neuer datensatz mit dem selben inhalt, aber er wurde ja zu einer anderen zeit erstellt.

cp an sich, wird immer nur das ihm ursprünglichst auferlegte tun, kopieren. das gilt ja für alle unix/linux befehle, um dies zu ändern wurden ja die parameter erfunden.

wo da jetzt die grundsatzdiskussion sein soll weiss ich nicht.

----------

## rblock

Das ist genau das was ich meine: Eine Grundsatzdiskussion.  :Smile: 

Denn es stellt sich nun die Frage: Was ist eine Kopie und was gehört dazu?

Um eines auszuschließen: Ein "mv" verschiebt eine Datei respektive nennt sie um. Also muss bei einem Umbenennen ein neues Datum gespeichert werden, da der Ursprungsname verändert wird.

Bei einem "cp" wird nur der "Lagerort" verändert, aber nicht der Inhalt! Was ist nun wichtiger, die Inhaltsveränderung oder die letzte Positionsveränderung. Ich meine nur: Wenn es in einem Warenlager zu einer Umstrukturierung kommt und die Artikel ihren Lagerort verändern, müssen dann die ureigensten Attribute des Artikels verändert werden? Denn es wird ja nicht der Artikel selbst verändert sondern nur sein Lagerort.  :Smile: 

Wenn Ihr eine DVD, eine CD, ein VHS Band oder irgendetwas anderes in Eurem Haushalt an einen anderen Aufbewahrungsort vreschiebt, ändert Ihr wirklich das Objekt selbst? Denn denn es wird bei einem "cp" ja nicht das Objekt selbst verändert, sondern sein Aufbewahrungsort. Und wenn ich mir eine Datei anschaue und das Datum betrachte, interessiert es mich absolut nicht, wann die Position verändert wurde sondern wann das Objekt selbst verändert wurde.

Unter OS/2 und Windoof wird dies IMHO richtig gehandhabt, nur hier...

Nachdenkliche Grüße

----------

## saccory

Lagerort verändern = Sache bewegen = mv

Neue Sache mit den Spezifikation einer bestehenden Sache = cp

----------

## Carlo

 *rblock wrote:*   

> Wenn Ihr eine DVD, eine CD, ein VHS Band oder irgendetwas anderes in Eurem Haushalt an einen anderen Aufbewahrungsort vreschiebt, ändert Ihr wirklich das Objekt selbst?

 

Nö, aber die Staubschicht wische ich wahrscheinlich ab.  :Wink:  Das Änderungsdatum ist imho Metainformation und nicht dem Dateiinhalt zuzurechnen. Dafür gibt's Versionskontrollsysteme oder auch Prüfsummen.

----------

## rblock

 *saccory wrote:*   

> Lagerort verändern = Sache bewegen = mv

 

Gut, Du hast recht, ich habe mich falsch ausgerückt. Ich erzeuge einen inhaltlichen Klon eines bestehenden Objekts und das an einem anderen Lagerort. Dazu dient u.a. der Symlink ("ln -s") unter Linux bzw. anderen Unixderivaten.  :Smile:   Aber u.U. ist dieser Link nicht das Richtige. Gehen wir auf die anderen OSes zurück. Unter diesen ist teilweise ein Move zwischen verschiedenen Partitionen nicht möglich. Daher muss man in diesem Fall kopieren. Aber ist deswegen der Inhalt verändert? Das ist eben die Frage: Was soll diese Attribut anzeigen? Es heißt ja "Datei geändert". Aber ist wirklich die Datei geändert, also ihr Inhalt? Oder eben "nur" eine Kopie an einem anderen Lagerort erstellt worden?

 *saccory wrote:*   

> 
> 
> Neue Sache mit den Spezifikation einer bestehenden Sache = cp

 

Ist die "Sache" neu oder nur der Lagerort? Was ist uns wichtig? Der Ort oder der Inhalt der Sache?

In den Jahren in der Systemprogrammierung (d.h. in der Hauptsache Systemkonfiguration) war uns eigentlich immer der Inhalt wichtig und nicht wo dieser Inhalt aufbewahrt wird. Denn ich muss ein System am Inhalt einer Datei konfigurieren und nicht anhand dessen wo er aufbewahrt wird, oder?  :Wink: 

Nachdenkliche Grüße

----------

## rblock

[quote="Carlo"] *rblock wrote:*   

> ...vreschiebt...

 

Ohhh man, was habe ich da geschrieben?  :Wink: 

 *Carlo wrote:*   

> Nö, aber die Staubschicht wische ich wahrscheinlich ab.  

 

Wir wissen nicht, wass dieser junge Mann empfiehlt, aber...  :Wink: 

 *Carlo wrote:*   

> Das Änderungsdatum ist imho Metainformation und nicht dem Dateiinhalt zuzurechnen. Dafür gibt's Versionskontrollsysteme oder auch Prüfsummen.

 

Klar, aber wie ich in dem Beitrag nach Deinem (es gab wohl eine Überschneidung) schrieb, habe ich lange Zeit in der Systemprogrammierung gearbeitet. Und da haben wir nicht nach Metainfos gesucht.  :Smile:   Allerdings kam es nachher soweit (weil irgendwelche genialen Hotlinemitarbeiter in den REXX-Scripten rumgepfuscht haben, dazu, dass wir auch vordefinierte Kommentarzeilen im Header der Dateien abgefragt haben, weil man sich auch auf das Datum nicht mehr verlassen konnte.  :Sad: 

Na ja, so wichtig ist das nun auch wieder nicht. Man muss eben mit den Eigenheiten der verschiedenen Systeme zurechtkommen, eben alles wissen. Wäre ja auch zu schön, wenn sich alle gleich verhalten würden. Daher gibt es auch keine wirklich systemübergreifende Programmierung.  :Smile: 

Schwindelige Grüße

----------

## Carlo

Du hast mit dem Einwand, daß man das so oder so sehen kann, gar nicht so unrecht. Mich würde mal interessieren, ob jemand einen Standard kennt, der sich explizit dazu ausläßt. Der Filesystem Hierarchy Standard befaßt sich nicht mit der Implementation der Kommandos, die Open Group Base Spezifikation erwähnt nur implizit (wie auch die man page [GNU, POSIX]), daß via -p das Datum beizubehalten ist...

...wer sucht weiter?

----------

## toskala

carlo: hohecker sie sind raus  :Smile: 

nein, ich denke halt, dass ein cp ein duplikat mit dem gleichen inhalt aber an einem neuen ort des datenträgers erzeugt. somit ist ein duplikat eine in sich neue sache, wohl zwar mit dem gleichen inhalt, aber eben ein duplikat.

ein duplikat ist eventuell das gleiche, aber nicht das selbe, und somit bekommt es einen neuen timestamp.

----------

## Carlo

 *toskala wrote:*   

> carlo: hohecker sie sind raus 

 

 :Confused:   :Question:   :Question: 

----------

## toskala

carlo, nicht böse gemeint, nur wegen dem schwarzen peter vom weitersuchen  :Smile: 

----------

## Carlo

Schon o.k. toskala, ich kann nur mit dem Spruch nichts anfangen. Ein mentaler Symlink auf /dev/zero sozusagen.

----------

## toskala

achso, na das ist so ein dummer spruch aus einer tv-comedy serie, muss man halt gesehen haben, als das man das irgendwie nachvollziehen kann

----------

