Fohnbit
Anmeldungsdatum: 31. August 2013
Beiträge: 170
|
Hallo, gibt es einen Möglichkeit einen Ordner zu verschieben, wenn der Inhalt (Files und Files in Unterordner) älter als x Jahre ist? Ich habe Projekt Ordner und diese sollen archiviert werden, wenn nach x Jahren keine Änderung stattgefunden hat. Ordnerstruktur ist:
Projekte
Projekt 1
Projekt 2
Projekte
Kunde 1
Projekt 1
Projekt 2
Kunde 2
Projekt 1
... Die Projekte, die unter den Kunden liegen, sollen archiviert werden Danke!
|
Vain
Anmeldungsdatum: 12. April 2008
Beiträge: 2503
|
Ungetestet: 1
2
3
4
5
6
7
8
9
10
11
12 | #!/bin/sh
years=3
for i in Kunde*
do
found=$(find "$i" -type f -mtime -$((365 * years)) -print -quit)
if [ -z "$found" ]
then
echo mv "$i" /some/place/else
fi
done
|
Klappert jedes Verzeichnis ab und wenn darin keine Dateien gefunden wurden, die jünger als $years Jahre sind, wird’s verschoben. Kannst du ja mal bei dir testen. Erst durch das Entfernen des echo würde es scharfgeschaltet werden.
|
Dakuan
Anmeldungsdatum: 2. November 2004
Beiträge: 6345
Wohnort: Hamburg
|
Sollte es nicht reichen, wenn man das Veränderungsdatum des Verzeichnisses abfragt?
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17552
Wohnort: Berlin
|
Dakuan schrieb: Sollte es nicht reichen, wenn man das Veränderungsdatum des Verzeichnisses abfragt?
Das kann man leicht prüfen:
1
2
3
4
5
6
7
8
9
10
11
12
13 | t201:~/proj/mini/forum/tmp/giftig > mkdir jetzt
t201:~/proj/mini/forum/tmp/giftig > l -d j*
drwxrwxr-x 2 stefan stefan 4096 Mär 2 00:00 jetzt
t201:~/proj/mini/forum/tmp/giftig > cd jetzt
t201:~/proj/mini/forum/tmp/giftig/jetzt > ls
t201:~/proj/mini/forum/tmp/giftig/jetzt > touch null 0
t201:~/proj/mini/forum/tmp/giftig/jetzt > l
insgesamt 24
drwxrwxr-x 2 stefan stefan 4096 Mär 2 00:00 .
drwxrwxr-x 6 stefan stefan 4096 Mär 2 00:00 ..
-rw-rw-r-- 1 stefan stefan 0 Mär 2 00:00 0
-rw-rw-r-- 1 stefan stefan 0 Mär 2 00:00 null
|
Verzeichnis mit 2 Dateien erstellt, alles um 0:00. | t201:~/proj/mini/forum/tmp/giftig/jetzt > cd ..
t201:~/proj/mini/forum/tmp/giftig > echo "eins" > jetzt/null
t201:~/proj/mini/forum/tmp/giftig > l jetzt
insgesamt 28
drwxrwxr-x 2 stefan stefan 4096 Mär 2 00:00 .
drwxrwxr-x 6 stefan stefan 4096 Mär 2 00:00 ..
-rw-rw-r-- 1 stefan stefan 0 Mär 2 00:00 0
-rw-rw-r-- 1 stefan stefan 5 Mär 2 00:01 null
t201:~/proj/mini/forum/tmp/giftig > l -d jetzt
drwxrwxr-x 2 stefan stefan 4096 Mär 2 00:00 jetzt
|
Datei "null" um 0:01 geändert, Verzeichnis "jetzt" bleibt bei 0:00 Uhr. Um 0:07:
| t201:~/proj/mini/forum/tmp/giftig > touch jetzt/7
t201:~/proj/mini/forum/tmp/giftig > l -d jetzt
drwxrwxr-x 2 stefan stefan 4096 Mär 2 00:07 jetzt
|
Einfügen einer neuen Datei ins Verzeichnis ändert dessen Zeitstempel, aber Ändern einer Datei nicht. Löschen einer Datei übrigens auch:
| t201:~/proj/mini/forum/tmp/giftig > rm jetzt/0
t201:~/proj/mini/forum/tmp/giftig > l -d jetzt
drwxrwx--x 2 stefan stefan 4096 Mär 2 00:11 jetzt
|
|
Fohnbit
(Themenstarter)
Anmeldungsdatum: 31. August 2013
Beiträge: 170
|
Vain schrieb: Ungetestet: 1
2
3
4
5
6
7
8
9
10
11
12 | #!/bin/sh
years=3
for i in Kunde*
do
found=$(find "$i" -type f -mtime -$((365 * years)) -print -quit)
if [ -z "$found" ]
then
echo mv "$i" /some/place/else
fi
done
|
Klappert jedes Verzeichnis ab und wenn darin keine Dateien gefunden wurden, die jünger als $years Jahre sind, wird’s verschoben. Kannst du ja mal bei dir testen. Erst durch das Entfernen des echo würde es scharfgeschaltet werden.
Super, vielen Dank!
|
Dakuan
Anmeldungsdatum: 2. November 2004
Beiträge: 6345
Wohnort: Hamburg
|
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8628
Wohnort: Münster
|
Dakuan schrieb: Sollte es nicht reichen, wenn man das Veränderungsdatum des Verzeichnisses abfragt?
Das hängt davon ab, welches Dateisystem man verwendet und wie dieses Dateisystem Verzeichnisse (Ordner, folder, directories) implementiert. Beim ext4-Dateisystem enthält ein Verzeichnis nur Dateinamen, deren Dateityp (Verzeichnis, reguläre Datei, Symlink usw.) und den ersten inode jeder Datei. Alles andere, auch die Metadaten jeder Datei wie z.B. die Zeitstempel sind nur über die inode jeder Datei zugänglich. Unter ext4 ändert sich also ein Verzeichnis, wenn Dateinamen hinzugefügt, verändert oder entfernt werden, man den Typ einer Datei ändert (wofür mir kein praktischer Sinn einfällt und ich weiß auch nicht, wie und ob man das überhaupt machen kann), sich die inode einer Datei ändert (was theoretisch beim Defragmentieren passieren könnte, aber ext4 defragmentiert man in der Praxis nicht).
Nur solche Änderungen ändern dann den Zeitstempel des Verzeichnisses in dessen inode, welche über den Dateinamen „.“ zugänglich ist.
|
Dakuan
Anmeldungsdatum: 2. November 2004
Beiträge: 6345
Wohnort: Hamburg
|
Mein Dateisystem ist ext4. Und meine Beobachtung basiert auf der täglichen Arbeit. Ich benutze Geany als Editor und übersetze meine Programme mit make. Wenn diese Programme die Zieldateien, sofern bereits vorhanden, immer löschen und dann neu erstellen, passt es zu dem was user_unknown sagt. Allerdings habe ich auch gerade einen Gegentest gemacht, der mich wieder verunsichert. Ich habe bei einer Bilddatei den eingebetteten Kommentar geändert und das Verzeichnis hatte danach das selbe Veränderungsdatum wie die Bilddatei. Grübel. Hätte ich doch meinen Schnabel gehalten.
|
rklm
Projektleitung
Anmeldungsdatum: 16. Oktober 2011
Beiträge: 12834
|
kB schrieb: Dakuan schrieb: Sollte es nicht reichen, wenn man das Veränderungsdatum des Verzeichnisses abfragt?
Das hängt davon ab, welches Dateisystem man verwendet und wie dieses Dateisystem Verzeichnisse (Ordner, folder, directories) implementiert.
Das müsste für alle Linux-Dateisysteme gleich sein.
Beim ext4-Dateisystem enthält ein Verzeichnis nur Dateinamen, deren Dateityp (Verzeichnis, reguläre Datei, Symlink usw.)
Der Typ ist nicht im Inode des Objektes gespeichert? Das würde mich wundern, denn dann könnte ein Verzeichnis als Typ "Datei" und ein anderes "Pipe" gespeichert haben. Das wäre Platzverschwendung im Verzeichnis und gefährliche Redundanz.
und den ersten inode jeder Datei.
Eine Referenz auf den Inode, oder?
Alles andere, auch die Metadaten jeder Datei wie z.B. die Zeitstempel sind nur über die inode jeder Datei zugänglich. Unter ext4 ändert sich also ein Verzeichnis, wenn
Genau.
Wie soll das gehen? Du kannst doch nicht plötzlich einen Unix-Domain-Socket in ein Verzeichnis verwandeln.
Meinst Du mit "Inode ändert sich", dass die Inode-Nummer eine andere wird? Aber dann ist es eine andere Datei, was Entfernen vom Verzeichnis plus hinzufügen entspricht. Wenn sich etwas an / in der Datei ändert (auch z.B. die Anordnung auf der Platte beim Defragmentieren), ändert sich keins der Verzeichnisse, die auf die Datei zeigen. Und das Defragmentieren erzeugt m.E. auch keinen neuen Inode, sondern ändert nur die Speicherstruktur. Das wird aber auch nicht die mtime der Datei ändern. Das wäre ein höllischer Seiteneffekt des Defragmentierens, denn dann kannst Du die mtime gleich vergessen.
Nur solche Änderungen ändern dann den Zeitstempel des Verzeichnisses in dessen inode, welche über den Dateinamen „.“ zugänglich ist.
Ich sehe das so: die mtime eines Verzeichnisses ändert sich, wenn man die Berechtigungen, Besitzer oder Gruppe des Verzeichnisses ändert oder Dateien einfügt oder entfernt.
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8628
Wohnort: Münster
|
rklm schrieb: […] die mtime eines Verzeichnisses ändert sich, wenn man die Berechtigungen, Besitzer oder Gruppe des Verzeichnisses ändert
Nein. (Ich habe es ausprobiert!)
oder Dateien einfügt oder entfernt
Ja, aber auch
beim Umbenennen einer Datei „im“ Verzeichnis, sowie bei einer Änderung der inode-Nummer einer Datei, was beim Defragmentieren passieren kann, wenn die Datei dabei in eine andere Blockgruppe verschoben wird, (Das entspricht aber effektiv der Erzeugung einer inkl. der Metadaten getreuen Kopie der Datei und Vernichtung der alten Datei. Ich habe einmal beim Defragmentieren merkwürdige Effekte beobachtet, die wir uns in Nachhinein so erklärt haben. Und „höllisch“ beschreibt es gut!) und rein theoretisch auch bei einer Änderung des Dateityps. (Was zwar keinen für mich erkennbaren praktischen Sinn ergibt, aber wenn das möglich sein sollte, dann müsste sich das genauso auswirken wie die anderen Ursachen.)
Der Dateityp gehört in die inode, wird aber bei neuen (Ich weiß aber nicht, ab welcher Version!) Versionen des Dateisystems auch redundant im Verzeichnis gespeichert. Das macht man wohl zur Verbesserung der Suchzeiten. Und ja: Redundant und gefährlich trifft zu, Platzverschwendung ist es aber nicht, denn man hat ein vorher verschwendetes Byte (was immer 0 war) in den neuen Versionen dafür neu definiert. Wer es genau nachlesen möchte: https://www.kernel.org/doc/html/latest/filesystems/ext4/index.html In Kürze: Die Zeitstempel von Verzeichnissen verhalten sich nicht immer so, wie die naive Metapher „Eine Datei ist ein Ding in einem anderen Ding (= Ordner).“ erwarten lässt.
|
rklm
Projektleitung
Anmeldungsdatum: 16. Oktober 2011
Beiträge: 12834
|
kB schrieb: rklm schrieb: […] die mtime eines Verzeichnisses ändert sich, wenn man die Berechtigungen, Besitzer oder Gruppe des Verzeichnisses ändert
Nein. (Ich habe es ausprobiert!)
Stimmt, es ist die ctime: 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21 | $ mkdir foo
$ stat foo
File: foo
Size: 0 Blocks: 0 IO Block: 4096 directory
Device: 1dh/29d Inode: 30118699 Links: 1
Access: (0775/drwxrwxr-x) Uid: ( 1000/ user) Gid: ( 1000/ user)
Access: 2020-03-03 11:02:58.431623130 +0100
Modify: 2020-03-03 11:02:58.431623130 +0100
Change: 2020-03-03 11:02:58.431623130 +0100
Birth: -
$ chmod -c a-w foo
mode of 'foo' changed from 0775 (rwxrwxr-x) to 0555 (r-xr-xr-x)
$ stat foo
File: foo
Size: 0 Blocks: 0 IO Block: 4096 directory
Device: 1dh/29d Inode: 30118699 Links: 1
Access: (0555/dr-xr-xr-x) Uid: ( 1000/ user) Gid: ( 1000/ user)
Access: 2020-03-03 11:02:58.431623130 +0100
Modify: 2020-03-03 11:02:58.431623130 +0100
Change: 2020-03-03 11:03:14.755973929 +0100
Birth: -
|
oder Dateien einfügt oder entfernt
Ja, aber auch
Klar, das ist ja wie Entfernen und Einfügen.
sowie bei einer Änderung der inode-Nummer einer Datei, was beim Defragmentieren passieren kann, wenn die Datei dabei in eine andere Blockgruppe verschoben wird, (Das entspricht aber effektiv der Erzeugung einer inkl. der Metadaten getreuen Kopie der Datei und Vernichtung der alten Datei. Ich habe einmal beim Defragmentieren merkwürdige Effekte beobachtet, die wir uns in Nachhinein so erklärt haben. Und „höllisch“ beschreibt es gut!)
Hm. Ich kann das nicht so recht glauben, dass Defragmentieren Inode-Nummern ändert. Da müssen dann ja alle Links aktualisiert werden und Prozesse, die auf die Datei zugreifen müssten das auch irgendwie mitbekommen, denn der Inode der Datei müsste der Schlüssel für den Zugriff sein. (Wenn man fstat() auf einem offenen Dateideskriptor aufruft, bekommt man u.a. die Inode-Nummer.) Schließlich soll Online-Defragmentierung keine sichtbaren Effekte auf den Betrieb haben außer, dass es vielleicht schneller wird.
Der Dateityp gehört in die inode, wird aber bei neuen (Ich weiß aber nicht, ab welcher Version!) Versionen des Dateisystems auch redundant im Verzeichnis gespeichert. Das macht man wohl zur Verbesserung der Suchzeiten. Und ja: Redundant und gefährlich trifft zu, Platzverschwendung ist es aber nicht, denn man hat ein vorher verschwendetes Byte (was immer 0 war) in den neuen Versionen dafür neu definiert.
Immerhin.
Wer es genau nachlesen möchte: https://www.kernel.org/doc/html/latest/filesystems/ext4/index.html
Danke! Muss ich mal in Ruhe lesen.
In Kürze: Die Zeitstempel von Verzeichnissen verhalten sich nicht immer so, wie die naive Metapher „Eine Datei ist ein Ding in einem anderen Ding (= Ordner).“ erwarten lässt.
Strenggenommen muss eine Datei ja noch nicht mal in einem Verzeichnis referenziert werden. Wenn sie entfernt wird, während ein Prozess noch auf sie zugreift, bleibt sie immer noch intakt und vorhanden. Dakuan schrieb:
Allerdings habe ich auch gerade einen Gegentest gemacht, der mich wieder verunsichert. Ich habe bei einer Bilddatei den eingebetteten Kommentar geändert und das Verzeichnis hatte danach das selbe Veränderungsdatum wie die Bilddatei. Grübel.
Das kann natürlich daher kommen, dass die Datei dabei neu geschrieben wird. Dann ändert sich natürlich auch das Verzeichnis. Du müsstest mal ein stat vor und nach der Änderung auf die Datei loslassen und dann die Nummer des Inode vergleichen.
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8628
Wohnort: Münster
|
rklm schrieb: […] Strenggenommen muss eine Datei ja noch nicht mal in einem Verzeichnis referenziert werden.
Ööhhh, doch! Dateinamen werden nur in Verzeichnissen gespeichert. Die inode einer Datei enthält keinen Dateinamen.
Wenn sie entfernt wird, während ein Prozess noch auf sie zugreift, bleibt sie immer noch intakt und vorhanden.
Entfernen einer Datei bedeutet die Löschung ihres letzten Namens aus einem Verzeichnis. Das Dateisystem markiert dann den inode als frei. Beim Zugriff auf alles, was in oder an diesem inode hängt, kann dann alles passieren. Manchmal kann man die gelöschte Datei sogar fehlerfrei lesen; Rettungswerkzeuge wie testdisk/photorec beruhen darauf. Verlässlich ist das aber nicht. Was theoretisch passieren könnte, aber niemals passieren sollte, ist die Löschung des letzten Dateinamens ohne Freigabe des inode. In diesem Fehlerzustand kann man allerdings die gelöschte Datei fehlerfrei lesen, sofern man ihren ehemaligen inode kennt, bis dieser wieder anders vergeben wird. Die Löschung eines weiteren Dateinamens (= hard link = Eintrag in einem Verzeichnis) hat allerdings gar keinen Einfluss auf die Gesundheit der eigentlichen Datei. Sie ist eben nur nicht mehr unter dem gelöschten Namen erreichbar.
|
rklm
Projektleitung
Anmeldungsdatum: 16. Oktober 2011
Beiträge: 12834
|
kB schrieb: rklm schrieb: […] Strenggenommen muss eine Datei ja noch nicht mal in einem Verzeichnis referenziert werden.
Ööhhh, doch! Dateinamen werden nur in Verzeichnissen gespeichert. Die inode einer Datei enthält keinen Dateinamen.
Datei != Dateiname
Wenn sie entfernt wird, während ein Prozess noch auf sie zugreift, bleibt sie immer noch intakt und vorhanden.
Entfernen einer Datei bedeutet die Löschung ihres letzten Namens aus einem Verzeichnis. Das Dateisystem markiert dann den inode als frei.
Nein.
Beim Zugriff auf alles, was in oder an diesem inode hängt, kann dann alles passieren. Manchmal kann man die gelöschte Datei sogar fehlerfrei lesen; Rettungswerkzeuge wie testdisk/photorec beruhen darauf. Verlässlich ist das aber nicht.
Ich habe den Eindruck, Du hast meinen Beitrag nicht richtig gelesen. Es war die Rede von dem Fall, dass es mindestens einen Prozess gibt, der die Datei geöffnet hat. So lange der letzte Dateideskriptor auf diese Datei nicht geschlossen wurde, bleibt die Datei immer intakt. Man findet sie halt nur nicht mehr.
Was theoretisch passieren könnte, aber niemals passieren sollte, ist die Löschung des letzten Dateinamens ohne Freigabe des inode. In diesem Fehlerzustand kann man allerdings die gelöschte Datei fehlerfrei lesen, sofern man ihren ehemaligen inode kennt, bis dieser wieder anders vergeben wird.
s.o.
|
Dakuan
Anmeldungsdatum: 2. November 2004
Beiträge: 6345
Wohnort: Hamburg
|
@rklm Ja, die Inodes haben sich geändert.
|