Kurze Antwort: Unix (und nicht nur Linux) speichert die creation time nicht. Das "am dichtesten dranste" ist die ctime, die Dir angibt wann der inode zum letzten mal geändert wurde. Das machen aber auch Befehel wie z.B. mv oder cp.
Längere Antwort: Daß mv oder cp die ctime ändern gibt Dir einen Hinweis auf das Problem mit der "creation time". Was ist das eigentlich? Wenn Du ein File kopierst oder umbenennst, was hat dann das neue File für eine "creation time"? Ist die Kopie oder das umbenannte File ein "neues" File mit eigener "creation time"? Oder sollten diese die "creation time" des alten übernehmen. Darüber kann man sich die Köpfe heißreden und wenn man das Filesystem einfach und frei von Überflüssigem oder Mehrdeutigem halten will (und das ist ja die alte Unix Philosophie) läßt man eben so etwas wie die "creation time" einfach weg und speichert statt dessen etwas eindeutig durch das Filesystem definiertes.
ich hätte für cp einfach eine neue creation time erhofft, denn es wird eine neue datei erstellt. bei mv könnte man sich in der tat streiten, daran habe ich wirklich nicht gedacht. da könnte der BDFL linus mal entscheiden. *feix*
die ctime ist mir bekannt, tut aber in meinen augen etwas ganz anderes, nämlich etwas mit bestehenden dateien.
aber ich sehe das problem... jedoch nur bei mv. in meinen augen sollte die creation time dann erhalten werden, denn die daten werden nicht neu angelegt, der platz nicht neu allokiert. wenn ich ein file umbenenne, lege ich kein neues file an, sondern ändere nur metadaten. wenn man eine datei also nur als die in ihm enthaltenen daten definiert, gibt es diese nur exakt 1x (mit beliebig vielen links drauf mit beliebig vielen namen) und damit nur ein einziges erstellungsdatum.
dass mv oder cp die ctime ändern, ist vollkommen io und verständlich.
vermutlich wurde diese diskussion aber mit genau meinen argumenten schonmal identisch geführt, ich möchte das also hier nicht hochkochen. das waren nur meine gedanken.
Kurze Antwort: Unix (und nicht nur Linux) speichert die creation time nicht. Das "am dichtesten dranste" ist die ctime, die Dir angibt wann der inode zum letzten mal geändert wurde. Das machen aber auch Befehel wie z.B. mv oder cp.
Längere Antwort: Daß mv oder cp die ctime ändern gibt Dir einen Hinweis auf das Problem mit der "creation time". Was ist das eigentlich? Wenn Du ein File kopierst oder umbenennst, was hat dann das neue File für eine "creation time"? Ist die Kopie oder das umbenannte File ein "neues" File mit eigener "creation time"? Oder sollten diese die "creation time" des alten übernehmen. Darüber kann man sich die Köpfe heißreden und wenn man das Filesystem einfach und frei von Überflüssigem oder Mehrdeutigem halten will (und das ist ja die alte Unix Philosophie) läßt man eben so etwas wie die "creation time" einfach weg und speichert statt dessen etwas eindeutig durch das Filesystem definiertes.
ich hätte für cp einfach eine neue creation time erhofft, denn es wird eine neue datei erstellt. bei mv könnte man sich in der tat streiten, daran habe ich wirklich nicht gedacht. da könnte der BDFL linus mal entscheiden. *feix*
die ctime ist mir bekannt, tut aber in meinen augen etwas ganz anderes, nämlich etwas mit bestehenden dateien.
aber ich sehe das problem... jedoch nur bei mv. in meinen augen sollte die creation time dann erhalten werden, denn die daten werden nicht neu angelegt, der platz nicht neu allokiert. wenn ich ein file umbenenne, lege ich kein neues file an, sondern ändere nur metadaten. wenn man eine datei also nur als die in ihm enthaltenen daten definiert, gibt es diese nur exakt 1x (mit beliebig vielen links drauf mit beliebig vielen namen) und damit nur ein einziges erstellungsdatum.
dass mv oder cp die ctime ändern, ist vollkommen io und verständlich.
vermutlich wurde diese diskussion aber mit genau meinen argumenten schonmal identisch geführt, ich möchte das also hier nicht hochkochen. das waren nur meine gedanken.
cu