mtime ändert sich beim verschieben eines Verzeichn. innerhalb XFS

Post Reply
Message
Author
XFS-Gast

mtime ändert sich beim verschieben eines Verzeichn. innerhalb XFS

#1 Post by XFS-Gast »

Hallo!

Hat jemand eine Idee, warum sich beim Verschieben eines Verzeichnisses (wirkliches Verschieben innherhalb eines FS, per mv oder mc <F6>) mtime ändert? Bei den enthaltenen Files (und Unterv.) wird mtime erhalten. Beim kopieren (cp -a ...) wird mtime korrekt übernommen.
Verschieben auf reiserfs macht nicht solchen Unfug, sondern verhält sich, wie von Unix-FS erwartet.
SuSE 9.3, 10.0, 10.1

Danke

klopskuchen
prolinux-forum-admin
Posts: 1444
Joined: 26. Jun 2004 21:18
Contact:

#2 Post by klopskuchen »

Eben probiert.
mkdir ~/aaa
touch ~/aaa/bbb
ls -ld ~/aaa
mtime=n
(zwei Minuten warten)
mv ~/aaa ~/var/
ls -ld ~/var/aaa
mtime=n

mtime bleibt gleich. Wobei ich mich frage warum du das kritisierst, schließlich wurde das Verzeichnis modifiziert. Und genau darüber soll mtime Aufschluß geben. Ohne in "mv" reingeguckt zu haben, dürften solche Aktionen mit rename() über die Bühne gehen. Da es laut deiner Aussage abhängig vom Dateisystem ist, solltest du dir die Quellen von mv und die der Dateisysteme zur Brust nehmen. Funktionsargumente sind für dein Problem zumindest laut mv-Doku nicht vorgesehen.


MfG, Klopskuchen
When all else fails, read the instructions .

XFS-Gast

#3 Post by XFS-Gast »

Kopskuchen,
ich danke für deine Mühe, aber von modifizieren war nicht die Rede, das wäre ja dann korrekt. Deiner Annahme betreff rename() stimme ich voll zu, wenn ich eine Hand frei habe, kann ich es ja mal direkt testen.

mkdir aaa
## ein x mehr, als versehentlich etwas zu wenig ...
mkdir varx
## mtime = n; x min warten
ls -ld aaa; sleep 61
## modifizieren ..
touch aaa/bbb
## mtime =n+x; KORREKT, aaa bekam bbb
ls -ld aaa
#
## bis hier also o.k.
#
## mtime = m; y min warten; ./ und ./varx liegen im selben Dateisystem
sleep 61
#rm -r varx/aaa ## fuer Wiederholungstäter
mv aaa varx/
ls -ld varx/aaa
## mtime(von aaa) = m + y; FALSCH für Unix Dateisysteme,
## denn in aaa wurde nichts geändert

Wenn sich im letzten Teil bei Klopskuchen (und anderen) mtime nicht ändert, ist das das richtige Verhalten unter Unix.
Statt Quellen zu studieren, hätte ich vielleicht auch schon einen Ansatz, wenn mir Klopskuchen verrät, unter welchen OS-Versionen er testete ...

MfG
XFS-Gast

klopskuchen
prolinux-forum-admin
Posts: 1444
Joined: 26. Jun 2004 21:18
Contact:

#4 Post by klopskuchen »

Slackware-current auf ext3 (coreutils-5.97) und Opensuse-10.0 auf Reiser-3.6 (coreutils-5.3.0).


MfG, Klopskuchen
When all else fails, read the instructions .

komsomolze
Posts: 430
Joined: 03. Mar 2006 23:16

#5 Post by komsomolze »

hier kann ich das Verhalten bestätigen (sarge mit 2.6.8-3)
im XFS ändert sich mtime beim Verschieben, nicht beim Umbenennen
in ext2 ändert sich die mtime auch beim Umbenennen

Lustig:
Nix passiert beim Verschieben von ext2 nach XFS oder vice-versa.

???

XFS-Gast

#6 Post by XFS-Gast »

Da hätte ich den Titel nochmal im Text wiederholen sollen:
... verschieben eines Verzeichn. innerhalb XFS

Habe die Sache noch auf einem Zenworks probiert: Auch Klopskuchen müsste zum selben (schlechten) Ergebnis auf Slackware kommen.

####

Wollte dieses seltsame Feature schon (allein) dem XFS zuschieben, da entdeckt Komsomolze (Von der SU lernen heißt siegen lernen!), dass ext2 da noch eines drauf setzt.
Habe es gerade an einem loop-dev probiert, auch auf einem ext3, als ext2 gemountet, ändert sich mtime eines Verzeichnisses auch bei seinem rename (alterName->neuerName). Reines ext3 verhält sich korrekt.
Lustig:
Nix passiert beim Verschieben von ext2 nach XFS oder vice-versa.
Gleiches bei ein_XFS -> anderes_XFS.
Da wird ja eh' kopiert, atime=ctime=mtime=jetzt und dann mittels kleiner grüner Männchen klammheimlich die Zeitmarke manipuliert. Bei mv (im Sinne rename) stell ich mir vor, dass das Userprogramm sich da gar nicht (nachträglich) kümmert, weil mtime eben unbeeinflusst bleiben soll.

Siesta.
Danke für den Einsatz, MfG
XFS-Gast

komsomolze
Posts: 430
Joined: 03. Mar 2006 23:16

#7 Post by komsomolze »

Lustig:
Nix passiert beim Verschieben von ext2 nach XFS oder vice-versa.
Gleiches bei ein_XFS -> anderes_XFS.
Da wird ja eh' kopiert, atime=ctime=mtime=jetzt
Das drückt nicht so ganz aus, was ich meinte:
Der Ordner auf dem anderen Dateisystem bekommt nicht "jetzt" als neue mtime, er "nimmt" seine mtime "mit".

XFS-Gast

#8 Post by XFS-Gast »

Naja, Dateisystemmäßig müsste es ein neues mtime geben, und danach wird erst mittels der kleinen grünen Männchen auf mitgenommenes mtime getrimmt. Ich kann mir nicht vorstellen, das es möglich ist, einer Datei gleich beim creieren ein explizietes mtime (u. a. ctime, atime) zu verpassen. Erst muss das Ding mal da sein, und dann können die Fälscher ans Werk gehen. Wenn das bei mv, cp ... in einem Zug (mit Lock) passiert, merkt ja keiner etwas davon.
Beim nur logischen Verschieben (renamen eben innerhalb eines FS) gehe ich (und mv ?) davon aus, dass das Filesystem dann mtime nicht ändert und somit kein Fälschungsbedarf (alte mtime mitnehmen) besteht.

####

Mir ist auch nicht in Erinnerung, dass ext2 (gab ja erst nicht anderes) früher solchen Unsinn machte. Außerdem sollten sich ja ext2 und ext3 gleich verhalten.

Mal schauen: steinalte Dstri betreff ext2 und auch mal selbst mit den sytemcalls spielen, Mann hat ja sonst nichts zu tun. Ist das bei Windos auch so schlimm?

Siesta vorbei. Nachtruhe.
MfG XFS-Gast

klopskuchen
prolinux-forum-admin
Posts: 1444
Joined: 26. Jun 2004 21:18
Contact:

#9 Post by klopskuchen »

> Da hätte ich den Titel nochmal im Text wiederholen sollen
:) Ja. Jetzt mit xfs unter besagtem Slackware probiert, ein Verzeichnis in ein anderes Verzeichnis auf selbiger Partition verschieben. Verhält sich genau so wie du sagst.

Weist du was neues? Würde mich mal interessieren. (Abgesehen vom lustigen "no such file..." auf ein fstat() auf $newfile *vor* rename() und ca. elfzig millionen Funktionen zwischen moves main und dem rename in einer anderen Datei.)


MfG, Klopskuchen
When all else fails, read the instructions .

Post Reply