staging.inyokaproject.org

wxpte schrieb:

rklm schrieb:

wxpte schrieb:

Was allerdings den Zeitpunkt der Geburt betrifft:

1 2 3 4

wxpte@rechner:~/testbock$ find . -newerBB Erste.txt find: Dieses System stellt keine Funktion zum Ermitteln der Erstellungszeit der Datei bereit. find: ungültige Option »-newerBB« wxpte@rechner:~/testbock$

Mit Ubuntu 22.04 leider Fehlanzeige, jedenfalls mit der vorinstallierten bash.

Wie kommst Du darauf?

Indem ich es ausprobiert habe. Umgekehrt gefragt: was liest du aus dem Zitat denn heraus?

s.o. Das hat rein gar nichts mit der bash zu tun.

Irgendwelche Zusammenhänge habe ich auch nicht behauptet. Ich habe lediglich berichtet, dass der Befehl find mit der angegebenen Option innerhalb der bash nicht funktioniert. Stimmt das nicht?

rklm schrieb:

Die Fehlermeldung kommt vom find - die bash hat rein gar nix damit zu tun. Mein btrfs gibt die Information auch an stat preis, aber find meckert wie bei Dir. Ich vermute, es liegt an der Art der Übersetzung von find oder einer Bibliothek, die find nutzt und die das (noch) nicht unterstützt. Es spricht einiges für letzteres, denn struct stat enthält keinen Zeitstempel für die Erzeugung der Datei. Dafür braucht man statx mit struct statx.

AFAIR gibt es unter Linux/Unix/POSIX keinen 'Geburts'-Zeitstempel, nur atime (letzter Zugriff), mtime (letzte Änderung) und ctime (letzte Änderung der Metadaten). Nur unter Windows gibt es die 'create time'.

dirkolus schrieb:

[…] AFAIR gibt es unter Linux/Unix/POSIX keinen 'Geburts'-Zeitstempel […]

Man kann leicht selbst testen, das dies Unsinn ist. Auf einem ganz normalen Ubuntu 22.04 mit ext4-Dateisystem:

$ stat ~/Vorlagen/
  Datei: /home/█████/Vorlagen/
 Größe: 4096      	Blöcke: 8          EA Block: 4096   Verzeichnis
Gerät: 80ah/2058d	Inode: 396468      Verknüpfungen: 2
Zugriff: (0750/drwxr-x---)  Uid: ( 1000/  █████)   Gid: ( 1000/   █████)
Zugriff: 2022-09-30 13:53:50.940074450 +0200
Modifiziert: 2022-04-08 14:06:15.952747048 +0200
Geändert: 2022-07-23 07:21:25.920532825 +0200
Geburt: 2022-04-07 00:20:17.580882479 +0200

Dies ist auch ein Beispiel für geändert ≠ modifiziert.

kB schrieb:

[..]

$ stat ~/Vorlagen/
  Datei: /home/█████/Vorlagen/
 Größe: 4096      	Blöcke: 8          EA Block: 4096   Verzeichnis
Gerät: 80ah/2058d	Inode: 396468      Verknüpfungen: 2
Zugriff: (0750/drwxr-x---)  Uid: ( 1000/  █████)   Gid: ( 1000/   █████)
Zugriff: 2022-09-30 13:53:50.940074450 +0200
Modifiziert: 2022-04-08 14:06:15.952747048 +0200
Geändert: 2022-07-23 07:21:25.920532825 +0200
Geburt: 2022-04-07 00:20:17.580882479 +0200

Brauchst Du vielleicht das Anonymisierungsskript, das ich geschrieben habe 😉?

user@penguin:~$ stat /home/user/
  File: /home/user/
  Size: 1482            Blocks: 0          IO Block: 4096   directory
Device: 31h/49d Inode: 39482       Links: 1
Access: (0755/drwxr-xr-x)  Uid: ( 1000/  user)   Gid: ( 1000/  user)
Access: 2022-09-30 16:41:14.129860745 +0200
Modify: 2022-10-01 09:19:12.666793321 +0200
Change: 2022-10-01 09:19:12.666793321 +0200
 Birth: 2022-04-10 08:01:04.378991338 +0200

kB schrieb:

Man kann leicht selbst testen, das dies Unsinn ist. Auf einem ganz normalen Ubuntu 22.04 mit ext4-Dateisystem:

$ stat ~/Vorlagen/
  Datei: /home/█████/Vorlagen/
 Größe: 4096      	Blöcke: 8          EA Block: 4096   Verzeichnis
Gerät: 80ah/2058d	Inode: 396468      Verknüpfungen: 2
Zugriff: (0750/drwxr-x---)  Uid: ( 1000/  █████)   Gid: ( 1000/   █████)
Zugriff: 2022-09-30 13:53:50.940074450 +0200
Modifiziert: 2022-04-08 14:06:15.952747048 +0200
Geändert: 2022-07-23 07:21:25.920532825 +0200
Geburt: 2022-04-07 00:20:17.580882479 +0200

Rein der Neugierde halber: hat zufällig jemand in Erinnerung, ob das unter 20.04 auch schon ging? (Ich möchte mir, nur um das auszuprobieren, jetzt nicht extra 20.04 wieder in VirtualBox installieren.)

karzer schrieb:

[…] Brauchst Du vielleicht das Anonymisierungsskript, das ich geschrieben habe 😉?

Zeigst Du mir Dein Ding, zeige ich Dir meine beiden 😉! Aber bitte nicht hier – OT!

wxpte schrieb:

Irgendwelche Zusammenhänge habe ich auch nicht behauptet. Ich habe lediglich berichtet, dass der Befehl find mit der angegebenen Option innerhalb der bash nicht funktioniert. Stimmt das nicht?

Ich zitiere:

wxpte schrieb:

Was allerdings den Zeitpunkt der Geburt betrifft:

1 2 3 4

wxpte@rechner:~/testbock$ find . -newerBB Erste.txt find: Dieses System stellt keine Funktion zum Ermitteln der Erstellungszeit der Datei bereit. find: ungültige Option »-newerBB« wxpte@rechner:~/testbock$

Mit Ubuntu 22.04 leider Fehlanzeige, jedenfalls mit der vorinstallierten bash. ☹ Mit ext4 hat das in diesem Fall nichts zu tun, das ist bei mir eingerichtet.

Nochmal: das hat mit der bash nichts, aber auch rein gar nichts zu tun. Es ist völlig egal, welcher Prozess find aufruft, ob das eine bash ist, eine sh, eine tcsh oder ein komplett anderes Programm.

Man kann sich davon mittels strace überzeugen, dass die Fehlermeldung von find kommt und nix mit der bash zu tun hat:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

$ strace -o x find -newerBB .
find: This system does not provide a way to find the birth time of a file.
find: invalid predicate `-newerBB'
$ tail -10 x
write(2, "find: ", 6)                   = 6
write(2, "This system does not provide a w"..., 68) = 68
write(2, "\n", 1)                       = 1
write(2, "find: ", 6)                   = 6
write(2, "invalid predicate `-newerBB'", 28) = 28
write(2, "\n", 1)                       = 1
close(1)                                = 0
close(2)                                = 0
exit_group(1)                           = ?
+++ exited with 1 +++

Und da stat z.B. den Wert ausgibt, wie man leicht überprüfen kann und auch kB gezeigt hat, hat es auch nichts mit dem Dateisystem oder dem Betriebssystem zu tun, sondern es liegt an find bzw. daran, welche Syscalls es (nicht) nutzt.

Wie man leicht sehen kann, nutzt stat den Aufruf statx, der die Information preisgibt, wie ich weiter oben gezeigt habe.

1
2
3

$ strace -o xx stat . >/dev/null
$ fgrep -w statx xx
statx(AT_FDCWD, ".", AT_STATX_SYNC_AS_STAT|AT_SYMLINK_NOFOLLOW, STATX_ALL, {stx_mask=STATX_ALL|STATX_MNT_ID, stx_attributes=0, stx_mode=S_IFDIR|0755, stx_size=2338, ...}) = 0

rklm schrieb:

Nochmal: das hat mit der bash nichts, aber auch rein gar nichts zu tun.

Das habe ich beim letzten Mal schon verstanden. Aber anscheinend hast du in meine Aussage weitaus mehr hineingelesen, als da stand:

find . -newerBB Erste.txt 

Mit Ubuntu 22.04 leider Fehlanzeige, jedenfalls mit der vorinstallierten bash.

heißt: der mit Ubuntu 22.04 auf der bash getestete Befehl ist fehlgeschlagen, wobei ich zu diesem Zeitpunkt noch nicht ausschließen wollte, dass es mit anderen shells funktioniert. Immerhin stand etwas zum Erstelldatum in der Manpage zu find. ⇒ Wie ich darauf komme? Genau das geht aus dem, was ich unmittelbar darüber in den Codeblock gesteckt hatte, hervor.

Dass es keinen Zusammenhang zwischen Fehlschlagen des find-Befehls und bash gibt, hast du in dem folgenden Post dann klargestellt. Wenn es weiter nichts gibt, was dir an meiner Aussage aufgestoßen ist, vergessen wir am besten das Ganze, es war dann wohl bloß ein Missverständnis.

wxpte schrieb:

[…] ob das unter 20.04 auch schon ging?

Das Dateisystem ext4 konnte mit Geburtstagen schon immer umgehen, aber dem Kernel fehlte eine Schnittstelle (xstat) zur Weitergabe der Information an die Anwendungssoftware. Statt xstat wurde vor einigen Jahren dann statx im Kernel implementiert. Nach Anpassungen in der Anwendungssoftware funktioniert es konkret, wenn:

• Kernel ab 4.11

• glibc ab 2.28

• GNU coreutils (enthält stat) ab 8.31

Bei Ubuntu 20.04 funktioniert es also gerade eben noch nicht.

Übrigens ist es exakt nicht der wirkliche Geburtszeitpunkt der Datei, sondern der Zeitpunkt der Entbindung dieser Datei aus deren Ursprung in dieses ext4-Dateisystem.

@kB: Danke für die Info.

@Scherz: Da mich das Thema auch selbst interessiert, habe ich mit dem Skript noch ein wenig herumexperimentiert. Wenn es dir also auf das Erstelldatum ankommt, dann müsstest du mit solch einem Skript weiterkommen:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

#!/bin/bash
# Umwandlung des Formats dd.mm.yyyy ins Format yyyy-mm-dd
ref=$(sed -E 's/([[:digit:]]{2})\.([[:digit:]]{2})\.([[:digit:]]{4})/\3-\2-\1/' <<< $1)
# Erzeugen einer temporären Datei mit allen Dateien in den Verzeichnissen
find /pfad/zum/ziel -type f > gefundene.tmp
while read neuer
do
   erstell=$(stat -c %W $neuer)
   if [ $erstell -ge $(date -d"$ref" +%s) ]
   then
     cp -p $neuer /pfad/zum/sichtungsverzeichnis/ 
   fi
done < gefundene.tmp
# temporäre Datei wieder löschen
rm gefundene.tmp

Tut mir leid, dass ich etwas penetrant bin.

wxpte schrieb:

rklm schrieb:

Nochmal: das hat mit der bash nichts, aber auch rein gar nichts zu tun.

Das habe ich beim letzten Mal schon verstanden.

Das konnte ich aus Deinen Antworten (9340038, 9340051, 9340068 - habe ich noch eine übersehen?) nicht entnehmen. Ich habe ja schon ein paar Superkräfte, aber Gedankenlesen gehört nicht dazu (worüber ich auch ganz froh bin, aber das ist nun wirklich ein ganz anderes Thema). 😉

Aber anscheinend hast du in meine Aussage weitaus mehr hineingelesen, als da stand:

find . -newerBB Erste.txt 

Mit Ubuntu 22.04 leider Fehlanzeige, jedenfalls mit der vorinstallierten bash.

heißt: der mit Ubuntu 22.04 auf der bash getestete Befehl ist fehlgeschlagen, wobei ich zu diesem Zeitpunkt noch nicht ausschließen wollte, dass es mit anderen shells funktioniert.

Hier kommen wir zum Kern des Pudels: Deine Aussage lässt mich vermuten, dass Du möglicherweise ein falsches Verständnis davon hast, wie die Shells mit Programmen interagiert bzw. wie generell Prozesse unter Linux / Unix funktionieren. Ich denke, das ist ein ziemlich fundamentaler Punkt der Funktionsweise des Betriebssystems, deshalb habe ich so auf der Sache mit der bash bestanden. Mir ging und geht es darum etwaige Missverständnisse auszuräumen.

rklm schrieb:

Deine Aussage lässt mich vermuten, dass Du möglicherweise ein falsches Verständnis davon hast, wie die Shells mit Programmen interagiert bzw. wie generell Prozesse unter Linux / Unix funktionieren.

Zumindest ein sehr oberflächliches Verständnis, möglicherweise auch falsch, das gebe ich zu.

Um dir zu vermitteln, wie meine Aussage zustande gekommen ist:

Erster Schritt: Blick in die Manpage von find:

B   Die Erstellungszeit der Datei Bezug

Mein Gedanke dazu: "Oh, find kann das also jetzt auch."

Zweiter Schritt: Ausprobieren. Ergebnis: die Optionen -newermm und -newercc funktionieren genau wie die klassischen -newer und -cnewer. Dagegen funktioniert -newerBB nicht wie erwartet. Mein Gedanke dazu: "Ohne Grund wird diese Option nicht in der Manpage aufgeführt. Also müsste es auch irgendeine Umgebung geben, in welcher diese Option funktioniert."

Natürlich könnte ich jetzt mit strace einige Untersuchungen anstellen – wenn ich denn mit den Ergebnissen etwas anzufangen wüsste. Aber so weit bin ich noch nicht. Ich hatte nur nicht erwartet, dass in der Manpage etwas dokumentiert wird, was (noch) nicht funktioniert. Daher hatte ich vermutet, dass diese Option unter bestimmten Voraussetzungen mit find schon verwendet werden kann.

Mhm.

Spitzfindigkeit: Nicht nur ext kennt Modifikationszeiten, sondern auch reiserfs und btrfs (definitiv), vielleicht auch xfs und zfs - hatte ich nie im Einsatz, squashfs (beliebt im Fanclublager von snap), proc, sysfs, ... die ganzen anderen, dynamischen Filesysteme probiere ich jetzt nicht aus. ☺

Jedenfalls habe ich mal ein btrfs-Filesystem angelegt

# muss über 100 MB groß sein, also eine 2er-Potenz über 200 gewählt, 128 hätte aber wohl auch gereicht.

1
2
3
4
5
6

dd if=/dev/zero of=./btrfs.loop bs=1M count=256 
# der --show-Schalter spuckt "loop17" aus, so dass man weiß, welches Loopdevice jetzt richtig ist.
# Snap, wenn man noch nicht fertig ist mit der Verbannung, belegt gerne mal 16 Loopdevices.
losetup --find --show ./btrfs.loop 
sudo mkfs -t btrfs /dev/loop17 
sudo mount /dev/loop17 ./btrfs 

Paar Dateien angelegt, paar Änderungen vorgenommen, paar Findaufrufe ausprobiert:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

root@t530:/media/stefan/tray3/test/btrfs# date >> date 
root@t530:/media/stefan/tray3/test/btrfs# stat date
  Datei: date
 Größe: 60        	Blöcke: 8          EA Block: 4096   Normale Datei
Gerät: 58h/88d	Inode: 258         Verknüpfungen: 1
Zugriff: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Zugriff: 2022-10-18 19:16:12.625204285 +0200
Modifiziert: 2022-10-18 20:10:30.120050760 +0200
Geändert: 2022-10-18 20:10:30.120050760 +0200
Geburt: 2022-10-18 19:16:12.625204285 +0200
root@t530:/media/stefan/tray3/test/btrfs# find -newerBB echo 
find: Dieses System stellt keine Funktion zum Ermitteln der Erstellungszeit der Datei bereit.
find: ungültige Option »-newerBB«

Also das ist kein Problem, welches an vfat gebunden ist - mit btrfs besteht es so auch.

user_unknown schrieb:

Also das ist kein Problem, welches an vfat gebunden ist - mit btrfs besteht es so auch.

Ja, weil es ein Problem von find ist. Das hatten wir aber schon herausgearbeitet, oder?