staging.inyokaproject.org

rklm schrieb:

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?

Mag sein, eine zweite Möglichkeit eine Hypothese zu prüfen kann aber nicht schaden.

user_unknown schrieb:

Mag sein, eine zweite Möglichkeit eine Hypothese zu prüfen kann aber nicht schaden.

Das sagt der, der sonst Quoting als Cargo-Cult-Programmierung ablehnt? 😀 😀 😀

rklm schrieb:

user_unknown schrieb:

Mag sein, eine zweite Möglichkeit eine Hypothese zu prüfen kann aber nicht schaden.

Das sagt der, der sonst Quoting als Cargo-Cult-Programmierung ablehnt? 😀 😀 😀

Ja. Ich sehe auch nicht, was der Test mit Cargo-Cult-Programmierung zu tun hat. Ist Dir das auf die Leber geschlagen? 😉

Ich habe noch nicht viel mit btrfs gemacht und hatte im Hinterkopf, dass es Dateigeburtstage speichert, war mir aber nicht mehr sicher. Und mit losetup habe ich nur 2-3 Mal kurz was gemacht, so dass ich die Wiederholung als Gelegenheit die Übung zu vertiefen wahrgenommen habe. Ich kenne auch nicht die Innereien von stat und find um zu wissen, ob die auf die gleichen Bibliotheken zugreifen und ob das identisch für vfat und btrfs ist.

Ich kenne auch nicht die Innereien von stat und find um zu wissen, ob die auf die gleichen Bibliotheken zugreifen und ob das identisch für vfat und btrfs ist.

Ich denke die werden alle alle auf die Systemfunktion "stat" und die gleichnamige Struktur zugreifen. Allerdings ist st_birthtime ursprünglich ein BSD Feature und wohl (noch) nicht auf allen Linux Systemen vorhanden.

Ich habe bisher keine Möglichkeit gefunden, wie man beim compilieren abfragen kann, ob dieses Feld dem jeweiligen Kernel bekannt ist.

p.s. Ich sehe gerade es gibt auch die Systemfunktion statx(). Allerdings weiß ich nicht seit wann.

Dakuan schrieb:

p.s. Ich sehe gerade es gibt auch die Systemfunktion statx(). Allerdings weiß ich nicht seit wann.

Steht in der Manpage:

statx() was added to Linux in kernel 4.11; library support was added in glibc 2.28.

Da gibt es wohl einige Unstimmigkeiten. Ein alter PC von mir hat:

@samurai:~$ uname -r
4.15.0-194-generic
~$

Danach sollte statx() verfügbar sein. Aber beim Versuch das zu nutzen sagt der Compiler:

vted.cpp: In member function ‘int MainWindow::find_max_size()’:
vted.cpp:1399:13: error: ‘statx’ was not declared in this scope
         if( statx( dir.c_str(), &statbuf ) == 0 ){
             ^~~~~
...

Die Header Datei ist dieselbe.Ich will damit nur andeuten, das es hier einige Unstimmigkeiten gibt. Mein Verdacht geht daher in die Richtung, dass es da irgendwie um ein Kommunikationsproblem geht. Ist aber nur ein Verdacht, da ich auch keine weiteren Hinweise habe und auch nicht die Zeit (und das Wissen) habe, den Quelltext zu analysieren.

Jedenfalls sollte es nicht sein, dass einige Programme einer Distribution ein vorhandenes Erstellungsdatum anzeigen können und andere nicht. Ich kann mir nicht vorstellen, dass die Macher von "find" das nicht auf die Reihe kriwegen. Da hätte ich eher Ubuntu im.Verdacht.

Allerdings muss ich zugeben, dass ich jetzt (noch) nicht auf meinem Debian System den Gegentest gemacht habe.