staging.inyokaproject.org

Ich kopiere mit eigenen Programmen Videodateien inklusive der zugehörigen Vorschaudateien. Letzteres ist mir wichtig, da diese manuell ausgewählte Frames enthalten.

Dabei passiert es aber immer wieder mal, dass die Vorschaudateien von den Dateimanagern nicht akzeptiert werden. Der Grund ist dann eine Differenz der MTime von einer Sekunde. Hinweis: Dateimanager sollen die Veränderungszeit der Datei und die, in der Vorschaudatei abgespeicherte Veränderungszeit der Originaldatei, auf exakte Gleichheit prüfen.

Eine Ursache dafür konnte ich schon ausmachen. Wie man hier nachlesen kann, hat das FAT Dateisystem (USB Stick) dafür nur eine Auflösung von 2 Sekunden. Aber diese Abweichung tritt gelegentlich auch auf, wenn ich Dateien über das Netzwerk kopiere. Daraus ergeben sich 2 Fragen:

• Gibt es solche Einschränkungen auch für andere Dateisysteme?

• Gibt es solche Einschränkungen auch für Netzwerkprotoklle (z.B. SMB)?

P.s. Ich benutze die Funktion stat() zum ermitteln der ursprünglichen MTime.

Das Problem ist noch etwas komplizierter als gedacht und betrifft auch Dateimanager (hier Caja). Zunächst scheint alles in Ordnung zu sein, da Linux wohl ein virtuelles Filesystem über den USB-Stick stülpt. Damit bleibt eine MTime mit ungerader Sekundenzahl erst mal erhalten.

Das bleibt so lange so, bis der USB-Stich ausgeworfen und wieder eingesteckt wird oder der Rechner neu gestartet wird. Dann erkennt Caja die vorgefundene(n) Vorschaudatei(en) als ungültig, da die darin notierte MTime eine Sekunde größer ist als im VFAT Dateisystem des USB-Sticks. Es werden sofort für alle Dateien mit vormals ungerader MTime neue Vorschaudateien erstellt.

Ich will jetzt mal versuchen, mittels statfs() das Dateisystem zu erkennen um dann vorbeugend tätig zu werden. Bisher habe ich bei mir folgende Dateisysteme vorgefunden:

EXT4_SUPER_MAGIC      0xef53
MSDOS_SUPER_MAGIC     0x4d44
SMB2_MAGIC_NUMBER     0xfe534d42

Bei SMB2 (NAS) tritt das Problem nicht auf. Aber ich konnte noch nicht testen, was passiert, wenn ich einen USB-Stck am NAS anschließe. SMB1 konnte ich auch nicht testen.

Ich kenne das Problem nicht und wusste bislang auch nichts, von diesem mtime-Phänomen bei USB-Sticks.

Wenn Du den Stick nicht auch unter Windows brauchst, dann kannst Du ihn aber auch mit ext4 formatieren, dann sollte er ja mtimes können. Ob das eine mögliche Problemlösung für Dich sein könnte, musst Du wissen.

Alternativ, aber auch etwas kompliziert, ist es, die Dateien in ein Archiv (zip etc.) zu packen und das Zip auf den Stick. Das Zip hat dann vielleicht ein ungenaues Datum, aber wenn Du es auspackst sollte es auf der Zielplattform, so diese mtime kann, funktionieren.

Das käme in Frage, wenn der Stick als Transportmedium für so dies und jenes eingesetzt wird.

Ich kenne das Problem nicht und wusste bislang auch nichts, von diesem mtime-Phänomen bei USB-Sticks.

Also eigentlich betrifft das alle VFAT Medien (exFAT konnte ich noch nicht testen).

Aber für mich ist das eigentlich nicht das große Problem, da ich ja durch einige Handgriffe das Problem umgehen bzw. reparieren kann. Aber vor einiger Zeit hatte mich einer der Supporter hier ermuntert mein Programm, zum erstellen individueller Vorschaudateien für Videos, zu veröffentlichen. Wenn ich so etwas irgendwann mal mache und ich solche Probleme nicht vermeiden kann, werden mir die Anwender mein Machwerk um die Ohren hauen.

Daher suche ich nach Möglichkeiten das zu vermeiden. Ein Anwender wird zu Recht enttäuscht sein, wenn durch dieses Phänomen die "handgemachten" Vorschaudateien von einem voreiligen Dateimanager einfach vernichtet werden. Daher meine Frage ob es dazu noch weiteres zu berücksichtigen gibt. Bisher habe ich nur FAT auf meinem Zettel.

Wobei noch anzumerken ist, dass durch eine manuelle Korrektur der MTime auch neue Probleme entstehen, die aber wahrscheinlich einfacher zu meistern sind. Es scheint ein Naturgesetz zu sein, dass durch die Beseitigung eines Problems immer zwei neue entstehen 👿

Ohne solche Probleme gehabt zu haben will ich eine kl. Spekulation beisteuern.

Wenn bei vfat nur jede 2. Sekunde als Dateidatum der Änderung benutzt werden kann, dann vermute ich, dass es für ctime und atime vielleicht ähnlich aussieht.

Wenn man jetzt nur die mtime ändert, um das Problem anzugehen, dann erzeugt man vielleicht Dateien deren Änderungszeit (mtime/ctime) vor der Geburtszeit (gibt es das überhaupt bei vfat?) liegt, was ein Widerspruch zur physikalischen Welt ist, und manche Tools könnten dadurch ins Stolpern kommen, aber eine konkretere Spekulation, wieso sie das sollten, habe ich auch nicht.

Hinweis: Dateimanager sollen die Veränderungszeit der Datei und die, in der Vorschaudatei abgespeicherte Veränderungszeit der Originaldatei, auf exakte Gleichheit prüfen.

Müssen die Zeiten gleich sein, oder darf nur die eine nicht eine Sekunde älter als die andere sein? Man kann ja die die Zeit der einen um eine Sekunde vorstellen oder die der anderen um eine zurück, um das zu heilen.

Noch eine Idee:

Es könnte nützlich sein, mit vielen Dateisystemen zu experimentieren, und mit Linux hat man dafür eine geeignete Plattform erwischt:

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

# leere Datei fixer Größe erzeugen:
dd if=/dev/zero of=./loop.img bs=8M count=8
# zu einem Loopdevice machen:
losetup --find --show ./loop.img
# Antwort des Systems mit Nr.:
# > /dev/loop1
# Das ganze Device zu einem durchgehenden Filesystem machen (formatieren), mit mkfs:
mkfs -t ext4 /dev/loop1
sudo mkdir /media/stefan/loopdevice
sudo mount /dev/loop1 /media/stefan/loopdevice
# ...
# Aushängen, unmounten:
sudo umount /dev/loop1
# Loopdevice entwidmen:
losetup --detach /dev/loop1

Wenn Du damit bereits vertraut bist will ich nichts geschrieben haben. ☺

Wenn bei vfat nur jede 2. Sekunde als Dateidatum der Änderung benutzt werden kann, dann vermute ich, dass es für ctime und atime vielleicht ähnlich aussieht.

Dazu hatte ich in meinem ersten Post einen Link beigesteuert. MS sagt dazu:

... Not all file systems can record creation and last access times, and not all file systems record them in the same manner. For example, the resolution of create time on FAT is 10 milliseconds, while write time has a resolution of 2 seconds and access time has a resolution of 1 day, so it is really the access date. The NTFS file system delays updates to the last access time for a file by up to 1 hour after the last access. ...

Aber du hast Recht. Das habe ich möglicherweise nicht zu Ende gedacht. Momentan maskiere das letzte Bit einfach weg. Beim gerade beendeten Versuch mit dem USB-Stick hat es funktioniert. Allerdings dauert der Schreibvorgang auch ca. 2 Sekunden. Mit einer rotierenden Platte hatte ich es noch nicht versucht. Vielleicht sollte ich zur Sicherheit noch 2 Sekunden dazu packen.

Müssen die Zeiten gleich sein, oder darf nur die eine nicht eine Sekunde älter als die andere sein?

Laut freedesktop.org müssen die gleich sein: Detect Modifications

Es könnte nützlich sein, mit vielen Dateisystemen zu experimentieren, ...

Würde ich gerne, geht aber hier nicht so einfach. Mein Win98 Rechner sollte noch laufen aber für Win2k müsste ich ein Netzteil von einem anderen PC ausleihen. Und um loop devices habe ich bisher einen Bogen gemacht. Ich sehe die immer nur zusammen mit Schnaps.

Bei meinem Versuch heute Nachmittag habe ich nur folgendes gemacht:

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

int MainWindow::copy_one_file( const char * dest, const char * src, int * res, bool vfat ) {
    ...
    struct      stat st_src;
    struct      stat st_dest;
    ...
    if( stat( src, &st_src ) == 0 ) {
        filetime.actime  = st_src.st_atime;
        filetime.modtime = st_src.st_mtime;
        if( vfat ) {
            filetime.actime  &= ~1;
            filetime.modtime &= ~1;
        }
    } else {
        return -1;
    }
    ...

Da sind aber mindestens 2 weitere Stellen, wo ich möglicherweise eingreifen muss.

Wenn man jetzt nur die mtime ändert, um das Problem anzugehen, dann erzeugt man vielleicht Dateien deren Änderungszeit (mtime/ctime) vor der Geburtszeit (gibt es das überhaupt bei vfat?) ...

Ich glaube nicht. Der Konsolenbefehl stat zeigt jedenfalls nichts an.

Aber mal folgendes Gedankenexperiment (in Ermangelung echter Testmöglichkeiten hier):
Eine Datei soll von Datenträger A (ohne creation time) auf Datenträger B (mit) kopiert oder verschoben werden und das unter Beibehaltung der MTime. Das ist ja nicht unüblich. Die Datei wird auf B angelegt (creation), es werden Daten kopiert und dann wird die Datei geschlossen (MTime). Anschließend wird die MTime der Originaldatei auf die Kopie übertragen. Diese liegt höchstwahrscheinlich vor der physikalischen creation-time. Ein Dateisystem solle, meiner Meinung nach, damit umgehen können. Ich würde mir wünschen, dass die creation-time in solchen Fällen korrigiert wird.

Für VFAT funktioniert das einfache Korrekturverfahren bisher gut. exFAT konnte ich noch nicht testen.

Dakuan schrieb:

Ein Dateisystem solle, meiner Meinung nach, damit umgehen können. Ich würde mir wünschen, dass die creation-time in solchen Fällen korrigiert wird.

Solange ich nicht selbst Fragen dazu habe leiste ich mir den Luxus der Ignoranz gegenüber der Frage. Sicher gibt es einerseits Dokumentation dazu, andererseits kann man es experimentell untersuchen.