Ubuntu (noch 16.04) Aber ich meine in 18 ist das auch so: Wie könnte ich hier mal den Eintrag "erstellt" statt immer nur "geändert" bekommen? BTW, wenn ich diese Anzeige habe, kann ich keinen Screenshot machen. Deshalb per Handy...
Angehängte Dateien:
-
ubuntu-screenshot.jpg
26 KB
● J-A V. schrieb: > diese Anzeige -? ls -? sollte alle Möglichkeiten zeigen. (Kommt allerdings auch etwas auf das Dateisystem an.)
Ich bin da nicht im Terminalfenster.
● J-A V. schrieb: > Ich bin da nicht im Terminalfenster. Falls dein Dateibrowser "Nautilus" heißt: Laut google gibt es da draußen sehr viele Leute die ein ähnliches Problem haben. Gibt auch einen Eindruck auf der wish-list. Scheinbar kann Nautilus das einfach nicht. Allerdings sind die Beiträge die ich gefunden habe von 2014, keine Ahnung ob sich seitdem was getan hat. Ah OK, grade gesehen, du hast Ubuntu 16.04. Dann stehen die Chancen groß dass dein Nautilus das einfach nicht kann. Spaßeshalber könntest du mal ein aktuelles live-Image verwenden und überprüfen, ob es da geht. Achja: das Dateisystem muss diese Info natürlich vorhalten. ext4 tut das.
:
Bearbeitet durch User
Ja, Nautilus hier. Le X. schrieb: > Spaßeshalber könntest du mal ein aktuelles live-Image verwenden und > überprüfen, ob es da geht. werde ich mal machen. Interessanterweise zeigt es noch nicht mal das "Erstellt" an, wenn ich mir die Info per Rechtsklick auf eine einzelne Datei anzeigen lasse. Da muss ich mir doch mal ansehen, ob ein vorher unter Windows vorhandenes "erstellt am" durch Kopie einer solchen Datei in Nautilus verloren geht. Also ob das in einem Dateibrowser, der das sonst kann, dann überhaupt noch besteht. Das zerkloppt einem ja dann eine nicht unwichtige Sortiermöglichkeit. Plötzlich sind alte Dateien, die heute kopiert wurden, "von heute" wa'? O_°
● J-A V. schrieb: > Da muss ich mir doch mal ansehen, ob ein vorher unter Windows > vorhandenes "erstellt am" durch Kopie einer solchen Datei in Nautilus > verloren geht. > > Also ob das in einem Dateibrowser, der das sonst kann, > dann überhaupt noch besteht. Das würde ich bezweifeln, der Dateibrowser wird ja selbst keine Bytes herumschaufeln sondern setzt auf system calls o. Ä. auf. Eine Datei sollte nach dem Kopiervorgang also gleich aussehen, inklusive Metainformation. Aber ausprobieren schadet sicher nicht. Eine größere Rolle dürfte das filesystem spielen. NTFS hält wohl auch zwei Einträge vor, für "erstellt" und "verändert". Wenn du beim Kopieren den Umweg über ein "schwächeres" filesystem gehst dann wird diese Info wohl verloren gehen.
● J-A V. schrieb: > BTW, wenn ich diese Anzeige habe, > kann ich keinen Screenshot machen. DRUCK-Taste benutzt?
h4x0r! schrieb: > ● J-A V. schrieb: >> BTW, wenn ich diese Anzeige habe, >> kann ich keinen Screenshot machen. > > DRUCK-Taste benutzt? öh... ja
● J-A V. schrieb: > Interessanterweise zeigt es noch nicht mal das "Erstellt" an, wenn ich > mir die Info per Rechtsklick auf eine einzelne Datei > anzeigen lasse. Diese Information gibt es schlicht nicht. Es gibt in Posix drei Zeitstempel für eine Datei: last access (atime), last modified (mtime), inode last changed (ctime). Beim Kopieren ändert sich zwangsweise die ctime, während man die mtime zurücksetzen kann. Warum allerdings Nautilus nur mtime und atime anzeigen kann, erschließt sich mir auch nicht.
Was für ein unseriöses Betriebssystem soll denn das sein? Ein Frickel-Linux oder ein Hipster-Mac? Nutz halt mal ordentliche Dinge.
Cyblord -. schrieb: > Was für ein unseriöses Betriebssystem soll denn das sein? Ein > Frickel-Linux oder ein Hipster-Mac? Nutz halt mal ordentliche Dinge. Hauptsache erstmal weg von Windows alles was ich sonst so brauche funktioniert ja.
:
Bearbeitet durch User
Cyblord -. schrieb: > Was für ein unseriöses Betriebssystem soll denn das sein? Ein > Frickel-Linux oder ein Hipster-Mac? Nutz halt mal ordentliche Dinge. Ubuntu ist "unseriös"? Aha... Und auf einem "Hipster-Mac" (was immer das sein soll) läuft Ubuntu? Aha... Was man hier alles lernen kann!
npn schrieb: > Cyblord -. schrieb: >> Was für ein unseriöses Betriebssystem soll denn das sein? Ein >> Frickel-Linux oder ein Hipster-Mac? Nutz halt mal ordentliche Dinge. > > Ubuntu ist "unseriös"? Aha... Natürlich. > Und auf einem "Hipster-Mac" (was immer das sein soll) läuft Ubuntu? > Aha... Habe ich nicht behauptet? Ich habe nach dem OS gefragt. > Was man hier alles lernen kann! Vor allem von mir, also lausche den Worten des Meisters und quatsch nicht so frech dazwischen.
Cyblord -. schrieb: > Habe ich nicht behauptet? Ich habe nach dem OS gefragt. Lesen kannst du auch nicht? ● J-A V. schrieb: > Ubuntu (noch 16.04) Cyblord -. schrieb: > lausche den Worten des Meisters Wenigstens hast du Humor, wenn's auch schwarzer ist.
Wir können gerne über meine unzureichenden Linux-Kenntnisse witzeln. Aber einen Flamewar über das "richtige" OS brauchen wir nicht.
npn schrieb: > Lesen kannst du auch nicht? Texte zu Unseriösen Dingen werden bei mir automatisch ausgeblendet. Lag wohl daran.
● J-A V. schrieb: > Aber einen Flamewar über das "richtige" OS brauchen wir nicht. Du nicht, ich auch nicht. Aber seine Lordschaft braucht das. Sonst fühlt er sich nicht als "Meister". Cyblord -. schrieb: > also lausche den Worten des Meisters --scnr--
Cyblord -. schrieb: > Texte zu Unseriösen Dingen werden bei mir automatisch ausgeblendet. Dann halt dich doch aus dem Thread raus. Zur Lösung willst du doch sowieso nichts beitragen. Folglich bleibt als Schlussfolgerung lediglich, dass es dein Vorsatz ist, den Thread zu stören. Das wiederum verbieten die Nutzungsbedingungen ganz eindeutig.
Jörg W. schrieb: > Zur Lösung willst du doch > sowieso nichts beitragen. Das ist eine infame Unterstellung, ich habe bereits in meinem ersten Post eine Lösung präsentiert. Nur weil sie dir nicht gefällt, ist sie dennoch da.
Cyblord -. schrieb: > ich habe bereits in meinem ersten Post eine Lösung präsentiert. Eine Lösung? Sorry, ich sehe nur FUD.
Cyblord -. schrieb: > Texte zu Unseriösen Dingen werden bei mir automatisch ausgeblendet. Lag > wohl daran. Die Automatik scheint kaputt zu sein, sonst wuerdest Du hier nicht stoeren. wendelsberg
● J-A V. schrieb: > BTW, wenn ich diese Anzeige habe, > kann ich keinen Screenshot machen. > Deshalb per Handy.. in der Console gnome-screenshot -d 3 eingeben und fertig. Nach 3 Sekunden wird automatisch ein Screenshot erzeugt. In der Zeit kannst du deinen Bildschirm vorbereiten (Menüs öffnen, irgendwas markieren, whatever). Die Bilder landen im "Pictures"-Verzeichnis (im Home-Ordner). ("d" steht für "delay" (in sec.))
Jörg W. schrieb: > Diese Information gibt es schlicht nicht. Doch, ext4 hat das, wie schon weiter oben von lex_91 festgestellt:
1 | # debugfs -R "stat abc/xyz" /dev/sda1 |
Das Gerät durch die gewünschte Partition ersetzen und abc/xyz ist der relative Pfad auf dieser Partition. Der gesuchte Eintrag ist crtime. stat alleine rückt diese Information nicht raus und da ls intern stat benutzt, kann auch ls davon nichts wissen. Über das Innenleben von Nautilus weiß ich zu wenig, aber dort wird es ähnlich sein. Für ext2/ext3 stimmt deine Aussage.
Heiner schrieb: > stat alleine rückt diese Information nicht raus Daher schrieb ich ja auch, dass Posix dies nicht hat (also das API). Daher nützt es eben selbst dann nichts, wenn man bspw. auf einem NTFS arbeitet (was das hat). Andererseits fehlen dem NTFS m.W. die anderen *time, die muss stat(2) dann also irgendwie emulieren. Da Posix normalerweise nur das standardisiert, was gängige Praxis und allgemein üblich ist, vermute ich, dass ein entsprechender Vorstoß, das in den Standard aufzunehmen, nicht unbedingt allgemeine Begeisterung hervorrufen dürfte.
Jörg W. schrieb: > Daher schrieb ich ja auch, dass Posix dies nicht hat (also das API). Darauf habe ich mich nicht bezogen, sondern auf die von mir zitierte Aussage: Jörg W. schrieb: > Diese Information gibt es schlicht nicht. Es ist völlig richtig, dass Posix' stat() diese Information nicht zurückgibt, trotzdem ist es falsch, dass es diese Information nicht gibt. Die Information liegt in ext4 vor, nur kann Nautilus (was über den Umweg von Tracker auch stat benutzt) auf diese Information nicht zugreifen.
Heiner schrieb: > Darauf habe ich mich nicht bezogen, sondern auf die von mir zitierte > Aussage: OK, diese war natürlich im Sinne des nachfolgenden Satzes zu verstehen, der das Posix-API ins Spiel gebracht hat. Wenn es kein API gibt für eine solche Information, hilft das halt den Applikationen nicht viel.
Gleiches gilt übrigens für ZFS, mit der Ausnahme, dass (mindestens) FreeBSD hier eine private Erweiterung für stat(2) implementiert hat, st_birthtim.
1 | The time-related fields of struct stat are as follows: |
2 | |
3 | st_atim Time when file data last accessed. Changed by the |
4 | mknod(2), utimes(2), read(2) and readv(2) system calls. |
5 | |
6 | st_mtim Time when file data last modified. Changed by the |
7 | mkdir(2), mkfifo(2), mknod(2), utimes(2), write(2) and |
8 | writev(2) system calls. |
9 | |
10 | st_ctim Time when file status was last changed (inode data |
11 | modification). Changed by the chflags(2), chmod(2), |
12 | chown(2), creat(2), link(2), mkdir(2), mkfifo(2), |
13 | mknod(2), rename(2), rmdir(2), symlink(2), truncate(2), |
14 | unlink(2), utimes(2), write(2) and writev(2) system |
15 | calls. |
16 | |
17 | st_birthtim Time when the inode was created. |
18 | |
19 | The following time-related macros are defined for compatibility: |
20 | |
21 | #define st_atime st_atim.tv_sec |
22 | #define st_mtime st_mtim.tv_sec |
23 | #define st_ctime st_ctim.tv_sec |
24 | #ifndef _POSIX_SOURCE |
25 | #define st_birthtime st_birthtim.tv_sec |
26 | #endif |
Weiß nicht, ob's die unter Solaris auch gibt.
Jörg W. schrieb: > Wenn es kein API gibt für eine solche Information, hilft das halt den > Applikationen nicht viel. Aber es hilft dem TE und das ist das Ziel: Er sucht also entweder einen Dateimanager, der nicht auf coreutils stat aufbaut (viel Glück ...), einen Workaround wie am Ende von [1], den man mit ausreichender Leidensfähigkeit auch in Nautilus integrieren könnte (viel Spaß ...), oder ein Betriebssystem, das ein solches Paradigma nativ, ohne irgendwelche Umwege unterstützt, dafür vielleicht andere Probleme hat. Die große Alternative ist, den eigenen Arbeitsablauf so zu verändern, dass man diese Funktion nicht braucht, aber das steht ja ebenfalls nicht zur Diskussion. [1] http://moiseevigor.github.io/software/2015/01/30/get-file-creation-time-on-linux-with-ext4/
Heiner schrieb: > Die große Alternative ist, den eigenen Arbeitsablauf so zu verändern, > dass man diese Funktion nicht braucht, aber das steht ja ebenfalls nicht > zur Diskussion. Die übliche Verfahrensweise ist ja beim Kopieren, dass man die mtime auf den originalen Wert zurücksetzt (die ctime kann man nicht setzen, das macht der Kernel). Genau die wird ja im Dateimanager ohnehin angezeigt (und auch bei ls -l auf der Kommandozeile standardmäßig).
Cyblord -. schrieb: > Vor allem von mir, also lausche den Worten des Meisters und quatsch > nicht so frech dazwischen. cyblöd at it's best... immer wieder erfrischend komisch :D 'sid
Cyblord -. schrieb: > Was für ein unseriöses Betriebssystem soll denn das sein? Das "seriöse" BS was Du vermutlich meinst, kennt nur 2 Zeiten: Erstelldatum. Änderungsdatum. Wenn ich mir jetzt eine Datei aus dem Internet herunterlade, ist das Downloaddatum das Erstelldatum. Jetzt meine Frage an den großen Meister: Was nützt mir das "Erstelldatum" jetzt?
Andreas B. schrieb: > Cyblord -. schrieb: >> Was für ein unseriöses Betriebssystem soll denn das sein? > > Das "seriöse" BS was Du vermutlich meinst, kennt nur 2 Zeiten: > Erstelldatum. > Änderungsdatum. Das ist entweder ein Audruck kompletter Unwissenheit oder schlimmer, eine bewußte Lüge. Davon kann sich jeder leicht überzeugen: https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getfiletime Inbesondere zur Lektüre durch dich empfohlen sei der "Remarks"-Abschnitt. > Wenn ich mir jetzt eine Datei aus dem Internet herunterlade, ist das > Downloaddatum das Erstelldatum. > Jetzt meine Frage an den großen Meister: Was nützt mir das > "Erstelldatum" jetzt? In diesem Moment vermutlich nix. Wenn ich aber in zwei Jahren aus irgendeinem Grund wissen will, wann ich diese Datei heruntergeladen habe, dann kann das sehr wohl eine nützliche Information sein.
c-hater schrieb: > Inbesondere zur Lektüre durch dich empfohlen sei der > "Remarks"-Abschnitt. Was nützt das, wenn das vor dem User verborgen bleibt? Der gemeine Browser, den man ja bei diesem seriösen BS nicht aussuchen kann, zeigt mir das jedenfalls nicht an. c-hater schrieb: > Wenn ich aber in zwei Jahren aus > irgendeinem Grund wissen will, wann ich diese Datei heruntergeladen > habe, dann kann das sehr wohl eine nützliche Information sein. Das ist eine Information, aber nicht die gewünschte, nämlich das Erstelldatum.
Heiner schrieb: > Aber es hilft dem TE und das ist das Ziel: Er sucht also entweder einen > Dateimanager, der nicht auf coreutils stat aufbaut (viel Glück ...), > einen Workaround wie am Ende von [1], den man mit ausreichender > Leidensfähigkeit auch in Nautilus integrieren könnte (viel Spaß ...), > oder ein Betriebssystem, das ein solches Paradigma nativ, ohne > irgendwelche Umwege unterstützt, dafür vielleicht andere Probleme hat. Wenn mich nicht alles täuscht zeigt mir mein Dateibrowser aber das Erstelldatum zusätzlich zum Änderungsdatum an. Müsste ich mal daheim überprüfen (Dolphin auf Plasma Desktop, Arch Linux Unterbau).
Posix unterstützt zwar nur atime, mtime und ctime, in Linux gibt es aber zusätzlich noch btime, was über statx() abgefragt werden kann:
1 | int statx(int dirfd, const char *pathname, int flags, |
2 | unsigned int mask, struct statx *statxbuf); |
3 | |
4 | struct statx { |
5 | ...
|
6 | /* The following fields are file timestamps */
|
7 | struct statx_timestamp stx_atime; /* Last access */ |
8 | struct statx_timestamp stx_btime; /* Creation */ |
9 | struct statx_timestamp stx_ctime; /* Last status change */ |
10 | struct statx_timestamp stx_mtime; /* Last modification */ |
11 | ...
|
12 | };
|
Auch die Kommandos stat und ls unterstützen die Birthtime:
1 | $ stat myfile |
2 | File: myfile |
3 | Size: 0 Blocks: 0 IO Block: 4096 regular empty file |
4 | Device: 803h/2051d Inode: 80778808 Links: 1 |
5 | Access: (0644/-rw-r--r--) Uid: ( 1000/ me) Gid: ( 1000/ me) |
6 | Access: 2020-07-23 09:29:09.456625050 +0200 |
7 | Modify: 2020-07-23 09:27:44.122227198 +0200 |
8 | Change: 2020-07-23 09:28:16.789302609 +0200 |
9 | Birth: 2020-07-23 09:25:16.747027376 +0200 |
10 | |
11 | $ ls -l --time birth myfile |
12 | -rw-r--r-- 1 me me 0 23. Jul 09:25 myfile |
Welche Dateibrowser die Birthtime anzeigen können, weiß ich nicht, weil ich solches zu sehr an Windows erinnerndes Teufelszeug nicht benutze ;-) ● J-A V. schrieb: > Ubuntu (noch 16.04) Diese Version stammt ziemlich sicher noch aus einer Zeit vor der Birthtime der Birthtime in Linux.
:
Bearbeitet durch Moderator
Yalu X. schrieb: > was über statx() abgefragt werden kann Hmm, schade, wieder ein inkompatibles Interface. :/ ¹) Wäre schön gewesen, wenn sich die Implementatoren vielleicht ja schon mal vor Posix einig gewesen wären … wenn es jetzt darum geht, das bei Posix zu standardisieren, dann hat wieder jeder seinen eigenen Vorschlag, und es muss erstmal verhandelt werden, warum man welchen davon am Ende favorisiert. ¹) Das meinte ich jetzt nicht als Kritik an Linux, sondern im Vergleich zur FreeBSD-Variante, die stattdessen struct stat erweitert hat.
:
Bearbeitet durch Moderator
c-hater schrieb: > Wenn ich aber in zwei Jahren aus irgendeinem Grund wissen will, wann ich > diese Datei heruntergeladen habe, dann kann das sehr wohl eine nützliche > Information sein. Unter unixoiden Systemen schaut man sich dafür die ctime an. Ist zwar nicht notwendig identisch zur birthtime, aber in solch einfachen Fällen wie einem Browser-Download ist sie es.
Jörg W. schrieb: > aber in solch einfachen Fällen > wie einem Browser-Download ist sie es. Nur ist sie gerade dann ziemlich nutzlos, denn wann ich die Datei heruntergeladen habe interessiert mich wenig. Georg
Jörg W. schrieb: > ¹) Das meinte ich jetzt nicht als Kritik an Linux, sondern im Vergleich > zur FreeBSD-Variante, die stattdessen struct stat erweitert hat. Eigentlich ist das nicht mehr wirklich abhängig vom FreeBSD vs Linux, sondern von der verwendeten Libc. Die ganzen stat funktionen müssten eigentlich über statx implementierbar sein. Die grösseren Linux Distributionen nutzen glaub ich glibc. Also müsste doch eigentlich nur mal jemand in der glibc das Feld in im stat struct ergänzen, und die stat syscalls auf den statx syscall umstellen, falls das nicht sowieso schon so gemacht wird. Die libcs sind sowieso schon lange kein 1:1 wrapper auf die Syscalls mehr.
georg schrieb: > Nur ist sie gerade dann ziemlich nutzlos, denn wann ich die Datei > heruntergeladen habe interessiert mich wenig. Dem c-hater war allerdings genau das so wichtig. Ansonsten stimme ich dir zu, daher ist der Default der Posixe ja auch die Anzeige der mtime (die kann man zurücksetzen, im Gegensatz zu ctime oder birthtime, die kann nur der Kernel setzen). ? DPA ? schrieb: > Die ganzen stat funktionen müssten eigentlich über statx implementierbar > sein. Normalerweise ist stat ein Syscall, keine Bibliotheksfunktion. Beim Posix-API bin ich mir gerade nicht ganz sicher, ob dieses Detail dort komplett festgeschrieben ist, aus Nutzersicht gebe ich dir Recht, da ist es einfach nur ein Aufruf in die libc, und wie es im Detail implementiert ist, ist egal.
Jörg W. schrieb: > Normalerweise ist stat ein Syscall, keine Bibliotheksfunktion. Wo denn? Unter Linux amd64 sieht das so aus: https://godbolt.org/z/7j14oe Da wird ein "normaler" Funktionsaufruf an das libc shared object draus ("<__xstat@plt>").
Jörg W. schrieb: > ? DPA ? schrieb: >> Die ganzen stat funktionen müssten eigentlich über statx implementierbar >> sein. > > Normalerweise ist stat ein Syscall, keine Bibliotheksfunktion. Die stat Syscalls im Kernel kann man nicht ändern, das würde bestehende Programme kaputt machen, und das versucht man zu vermeiden. Deshalb gibt es den statx syscall. Die Wrapperfunktion der Libc anzupassen ist hier hingegen weniger Problematisch. Bestehende Programme kann man einfach neu kompilieren, und falls man den Sourcecode nicht hat, kann man weiterhin die alte Libc für das spezifische Programm verwenden.
? DPA ? schrieb: > Die stat Syscalls im Kernel kann man nicht ändern Irgendwie hat FreeBSD das geschafft (dir birth time hängt natürlich ganz hinten dran), habe mir aber nicht angesehen, wie sie das genau gedreht haben.
DPA schrieb: > Hatte FreeBSD denn schonmal eine Version von stat ohne st_birthtim? Sicher, das Projekt gibt's ja seit 1993. :) Gerade nachgesehen, sie ist (damals noch als st_creattime) 2002 mit den Patches für UFS2 hinzu gekommen. Eine größere Veränderung war es dagegen, inode-Nummern auf 64 bits aufzuweiten.
Andreas B. schrieb: > Das ist eine Information, aber nicht die gewünschte, nämlich das > Erstelldatum. Doch, natürlich ist es das Erstelldatum der Datei im lokalen Filesystem. Die ist ja nur das Image eines Streams, aber nicht notwendigerweise eine Kopie einer Datei. Dementsprechend gibt es keine Metainformationen einer Quelldatei. Nur aus dem Kontext, in dem der Stream bereitgestellt wird, kann ein Browser u.U. Teile der ursprünglichen Metainformation entnehmen. Wenn sie authentisch sind und die Quelle überhaupt eine Datei war...
c-hater schrieb: > Nur aus dem Kontext, in dem der Stream bereitgestellt wird, kann ein > Browser u.U. Teile der ursprünglichen Metainformation entnehmen. Wenn er diese Information nicht hat, dann ist sowieso mtime = ctime (oder mtime = crtime). Das Rücksetzen der mtime kann er ja nur machen, wenn er eine solche Information überhaupt hat.
Angehängte Dateien:
-
honk_evidence.png
140 KB
Andreas B. schrieb: > Was nützt das, wenn das vor dem User verborgen bleibt? Bleibt es nicht. Wenn man es will, kann man es sich auch anzeigen lassen. Siehe Screenshot...
c-hater schrieb: > Andreas B. schrieb: > >> Was nützt das, wenn das vor dem User verborgen bleibt? > > Bleibt es nicht. Wenn man es will, kann man es sich auch anzeigen > lassen. Siehe Screenshot... Nur auf seriösen Betriebssystemen klappt das "einfach so" wie man sieht.
Angehängte Dateien:
Le X. schrieb: > Das würde ich bezweifeln, der Dateibrowser wird ja selbst keine Bytes > herumschaufeln sondern setzt auf system calls o. Ä. auf. Sicher? Kennst du einen system call, der Informationen über den Kopierverlauf ausgibt? Graphische Programme zeigen ja üblicherweise einen Verlaufsbalken an. Le X. schrieb: > Wenn mich nicht alles täuscht zeigt mir mein Dateibrowser aber das > Erstelldatum zusätzlich zum Änderungsdatum an. > Müsste ich mal daheim überprüfen (Dolphin auf Plasma Desktop, Arch Linux > Unterbau). Ja, tut er. In meinem Fall auf einem Kubuntu. Dateisystem ist btrfs. sid schrieb: > cyblöd at it's best... immer wieder erfrischend komisch :D Nö, nur irgendwie nervig - wie ein Pickel oder so.
Rolf M. schrieb: > Graphische Programme zeigen ja üblicherweise einen Verlaufsbalken an. Die greifen bei sowas auch gern mal daneben, dieweil sie nur irgendeine Schätzung abliefern. Krassester Fall, schon ein paar Jährchen her: ein PPP-Client, der sich von einem Windows via ISDN auf einem Router einloggen sollte. Während das Log auf dem Router sofort konstatiert, dass das übermittelte Passwort falsch ist, rödelt der Grafikbalken auf dem Client noch mehrere Sekunden lang herum, bis er dann mal feststellt, dass sich die Verbindung nicht aufbauen ließ. Die Information hätte der Client natürlich auch sofort zur Verfügung gehabt, aber irgendwie passte das zeitlich wohl nicht in die Darstellung des schicken Fortschrittsbalkens …
Jörg W. schrieb: > Die greifen bei sowas auch gern mal daneben, dieweil sie nur irgendeine > Schätzung abliefern. Frage: Gibt es da überhaupt einen besseren Weg außer einer groben Schätzung basierend auf der bisher erreichten Geschwindigkeit und der Restgröße? Das ist doch praktisch gar nicht anders möglich.
Aber immerhin HATTE es den Balken. Ich liebe ja nichts mehr als irgendwelche Funktionen ohne Fortschrittsanzeige.
Cyblord -. schrieb: > Gibt es da überhaupt einen besseren Weg außer einer groben Schätzung > basierend auf der bisher erreichten Geschwindigkeit und der Restgröße? Für normales Dateikopieren: klar, man kann massig Synchronisationspunkte reinwerfen (fsync, da hat Windows sicher ein Pendant), aber dann hat man eine schöne Fortschrittsanzeige und eine lausige Performance. Für besagtes PPP hätte es sicher eine bessere Lösung geben können. Das war wohl ein Designproblem der GUI.
Jörg W. schrieb: > Rolf M. schrieb: >> Graphische Programme zeigen ja üblicherweise einen Verlaufsbalken an. > > Die greifen bei sowas auch gern mal daneben, dieweil sie nur irgendeine > Schätzung abliefern. Ja, aber dennoch braucht man dafür ja irgendeinen Anhaltspunkt. Eine API, die eine Kopierfunktion hat, die nichts weiter bietet, als am Schluss Informationen über Erfolg oder Fehler auszugeben, bietet nicht viele Möglichkeiten für so einen Balken. Deshalb wird meistens dann doch kein Kopier-Systemcall direkt verwendet, sondern eben "von Hand" kopiert. Dann muss sich das Programm aber natürlich auch selbst um die korrekte Übertragung der "erstellt"-Zeit kümmern. > Krassester Fall, schon ein paar Jährchen her: ein PPP-Client, der sich > von einem Windows via ISDN auf einem Router einloggen sollte. Während > das Log auf dem Router sofort konstatiert, dass das übermittelte > Passwort falsch ist, rödelt der Grafikbalken auf dem Client noch mehrere > Sekunden lang herum, bis er dann mal feststellt, dass sich die > Verbindung nicht aufbauen ließ. Die Information hätte der Client > natürlich auch sofort zur Verfügung gehabt, aber irgendwie passte das > zeitlich wohl nicht in die Darstellung des schicken Fortschrittsbalkens Solche Sachen sehe ich in letzter Zeit öfter, vor allem unter Android und unter Windows. Ein Fortschrittsbalken, der munter steigt und suggeriert, dass etwas passiert, z.B. beim Öffnen einer Webseite. Irgendwann ist er dann fast bei 50%, und dann kommt auf einmal die Meldung, dass gar kein Kontakt zum Server aufgebaut werden konnte. Das kann einem sogar passieren, wenn eine Internet-Verbindung überhaupt nicht besteht. Ich fühle mich da immer ziemlich verarscht, wenn das Ding mir Aktivität vorgaukelt, die gar nicht statt findet. Jörg W. schrieb: > Cyblord -. schrieb: >> Gibt es da überhaupt einen besseren Weg außer einer groben Schätzung >> basierend auf der bisher erreichten Geschwindigkeit und der Restgröße? > > Für normales Dateikopieren: klar, man kann massig Synchronisationspunkte > reinwerfen (fsync, da hat Windows sicher ein Pendant), aber dann hat man > eine schöne Fortschrittsanzeige und eine lausige Performance. Es gibt auch oft den Fall, dass der Fortschritt nur auf Basis des Cache angezeigt wird und nicht darauf, wie viele Daten tatsächlich schon auf dem Datenträger angekommen sind. Das sind dann diese berühmten Balken, die in kürzester Zeit auf 99% hoch schießen und dann 5 Minuten lang da stehen bleiben. Die Frage ist: Bekommt man irgendwie raus, wieviel wirklich schon angekommen ist, ohne dazu gleich das Caching aushebeln zu müssen?
:
Bearbeitet durch User
Beitrag #6348400 wurde vom Autor gelöscht.
Rolf M. schrieb: > Le X. schrieb: >> Das würde ich bezweifeln, der Dateibrowser wird ja selbst keine Bytes >> herumschaufeln sondern setzt auf system calls o. Ä. auf. > > Sicher? Kennst du einen system call, der Informationen über den > Kopierverlauf ausgibt? Graphische Programme zeigen ja üblicherweise > einen Verlaufsbalken an. Sicher bin ich mir nicht, es würde mich aber schon sehr wundern wenn z.B. Dolphin direkt auf Blockdevices wie /dev/sdxn operiert und da munter einzelne Bytes durch die gegend schaufelt. Die werden entweder einen syscall verwenden oder auf ein executable aufsetzen welches selber schon etwas Kopierkosmetik mitbringt. Kannst du mehr dazu sagen wie Dolphin einen Kopiervorgang intern handhabt? Und der Fortschrittsbalken ist nun wirklich kein Argument. Der wird anhand diverser Faktoren geschätzt, im Endeffekt kann ich aber genauso gut würfeln ;-)
:
Bearbeitet durch User
Le X. schrieb: > Kannst du mehr dazu sagen wie Dolphin einen Kopiervorgang intern > handhabt? Wenn ich sowas machen müsste, würde ich fread() und fwrite() benutzen … Durch das Caching allerdings ist die Rate am Anfang extrem hoch, denn die Zieldaten landen ja erstmal im Cache, fwrite() kann sofort zurückkehren. Nun kann man für einen "schönen" Fortschrittsbalken dann fsync() zwischendrin machen, aber man büßt damit insgesamt Performance ein. Alternativ (und ich glaube, sowas wird wirklich gemacht), man macht die fsync() nur, wenn es sich um ein externes Speichermedium handelt: dort will der Nutzer am Ende ja oft genug das Medium möglichst schnell wieder entfernen, da muss er sowieso warten. Da kann man ihn auch zwischendurch warten lassen und ihm so eine bessere Schätzung geben, ob er sich bis zum Ende des Vorgangs noch einen Kaffee holen kann. ;-)
Jörg W. schrieb: > Für normales Dateikopieren: klar, man kann massig Synchronisationspunkte > reinwerfen (fsync, da hat Windows sicher ein Pendant), aber dann hat man > eine schöne Fortschrittsanzeige und eine lausige Performance. Kann man sich unter Windows sparen, da gibt es eine passende Api zum Kopieren (und auch eine zum Verschieben), samt Callback für den Fortschritt: "CopyFileEx". Was auch den entscheidenden Vorteil hat wirklich die komplette Datei zu kopieren: "This function preserves extended attributes, OLE structured storage, NTFS file system alternate data streams, security resource attributes, and file attributes."
guest schrieb: > Kann man sich unter Windows sparen, da gibt es eine passende Api zum > Kopieren Unter Windows gibt es ja auch für alles ein API – manchmal auch mehrere davon. ;-)
Le X. schrieb: > Rolf M. schrieb: >> Le X. schrieb: >>> Das würde ich bezweifeln, der Dateibrowser wird ja selbst keine Bytes >>> herumschaufeln sondern setzt auf system calls o. Ä. auf. >> >> Sicher? Kennst du einen system call, der Informationen über den >> Kopierverlauf ausgibt? Graphische Programme zeigen ja üblicherweise >> einen Verlaufsbalken an. > > Sicher bin ich mir nicht, es würde mich aber schon sehr wundern wenn > z.B. Dolphin direkt auf Blockdevices wie /dev/sdxn operiert und da > munter einzelne Bytes durch die gegend schaufelt. Nein, das natürlich nicht. Aber er wird die Eingangs-Datei lesen über read() und die Daten per write() in die Zieldatei schreiben. Das Erstellungsdatum wird dabei nicht automatisch übernommen, da aus Sicht des Systems die beiden Dateien ja erst mal nichts mit einander zu tun haben. Und genau darum ging's ja eigentlich: Die Behauptung, dass Programme wie Dolphin oder Nautilus einen fertigen Kopier-Systemcall verwenden würden, der sich automatisch um dieses Thema kümmert. Selbst das Kommandozeilentool cp nutzt zumindest unter Linux read()/write(), da es einfach keinen Systemcall zum kopieren gibt. https://stackoverflow.com/a/17666950 > Die werden entweder einen syscall verwenden oder auf ein executable > aufsetzen welches selber schon etwas Kopierkosmetik mitbringt. > Kannst du mehr dazu sagen wie Dolphin einen Kopiervorgang intern > handhabt? Früher wurden dazu mal kioslaves verwendet, aber ob's die noch gibt, weiß ich nicht. Ich hab schon lange nicht mehr in die KDE-Sourcen geschaut. > Und der Fortschrittsbalken ist nun wirklich kein Argument. > Der wird anhand diverser Faktoren geschätzt, im Endeffekt kann ich aber > genauso gut würfeln ;-) Dennoch wird das Programm ja irgendwo einen Anhaltspunkt für den Fortschritt her holen. Jörg W. schrieb: > guest schrieb: >> Kann man sich unter Windows sparen, da gibt es eine passende Api zum >> Kopieren > > Unter Windows gibt es ja auch für alles ein API – manchmal auch mehrere > davon. ;-) Wie man ja schon an dem "Ex" am Ende des Namen sieht, sind es in diesem Fall wohl auch mehrere.
Rolf M. schrieb: > Wie man ja schon an dem "Ex" am Ende des Namen sieht, sind es in diesem > Fall wohl auch mehrere. Ja, ohne "Ex" gibt es halt keinen Progresscallback. "CopyFile2" gibt es auch noch, da gibt es im Callback noch ein paar mehr/andere Infos. Und dann wäre da noch sowas wie "SHFileOperation" und das "IFileOperation interface". Ist unter Windows ja auch nötig. Wer will sich denn schon mit den ganzen Spezialitäten von NTFS rumschlagen, da kann man ja an eine Datei nahezu beliebige, mehr oder weniger versteckte Daten dranpatchen wie man grad Lust und Laune hat.
Angehängte Dateien:
c-hater schrieb: > Andreas B. schrieb: > >> Was nützt das, wenn das vor dem User verborgen bleibt? > > Bleibt es nicht. Wenn man es will, kann man es sich auch anzeigen > lassen. Siehe Screenshot... Mit einen Erstelldatum, das jünger ist als das Änderungsdatum. Sehr seriös!
Andreas B. schrieb: > Mit einen Erstelldatum, das jünger ist als das Änderungsdatum. Sehr > seriös! Was meinst du mit "seriös"? Alle drei Daten sind natürlich mit den entsprechenden Rechten beliebig manipulierbar, schließlich gibt es nicht nur einen API-Call für GetFileTime, sondern auch das Pendant für's Schreiben namens SetFileTime. Sie können also bestenfalls so "seriös" sein wie der Betreiber des Systems...
c-hater schrieb: > Andreas B. schrieb: > >> Mit einen Erstelldatum, das jünger ist als das Änderungsdatum. Sehr >> seriös! > > Was meinst du mit "seriös"? > > Alle drei Daten sind natürlich mit den entsprechenden Rechten beliebig > manipulierbar Da ist nichts manipuliert, das ist einfach nur Microsoft-Philosophie.
c-hater schrieb: > Sie können also bestenfalls so "seriös" sein wie der Betreiber des > Systems... nö, das ist schlicht das Downloaddatum, das hier als Erstelldatum bezeichnet wird. Da wurde in diesem Sinne nichts manipuliert. Mit seriös spiele ich im übrigen auf die Benennung des "unseriösen" BS von Cyblord an. Wir können es auch abkürzen: Bei keinem OS hat man ein richtiges Erstelldatum. Das bekommt man nur über irgendwelche Metainformationen (z.B. exif).
Andreas B. schrieb: > Bei keinem OS hat man ein richtiges Erstelldatum. Das, was im Filesystem als Erstelldatum eingetragen wird, ist das Dateierstelldatum. Beim Kopieren einer Datei wird eine neue Datei erstellt, deswegen bekommt diese auch ein neues Dateierstelldatum. Der Dateiinhalt wird dabei natürlich nicht neu erstellt, aber für das Inhaltserstelldatum gibt es auch keinen Eintrag im Filesystem. Das muss dann durch ein Anwendungsprogramm in die Datei selber geschrieben werden, wie Andreas B. schrieb: > z.B. exif
:
Bearbeitet durch Moderator
Yalu X. schrieb: > Beim Kopieren einer Datei wird eine neue Datei > erstellt, deswegen bekommt diese auch ein neues Dateierstelldatum. Genau das ist eben das Problem.
Andreas B. schrieb: > Yalu X. schrieb: >> Beim Kopieren einer Datei wird eine neue Datei >> erstellt, deswegen bekommt diese auch ein neues Dateierstelldatum. > > Genau das ist eben das Problem. Das Problem ist IMHO eher eine falsche Erwartungshaltung des Nutzers. Mich hat das ehrlich gesagt noch nie gestört. Ein aus meiner Sicht größeres Problem ist die oft unterschiedliche Behandlung des Änderungsdatums durch verschiedene Anwendungen. Manche Anwendungen betrachten das Erstellen einer Datei gleichzeitig auch als Änderung, andere hingegen nicht. Beim copy-Befehl in MSDOS und Windows ist es noch komplizierter: Da hängt es von der Art der Quelle ab, ob als Änderungsdatum das Änderungsdatum der Quelle oder das Erstelldatum der neuen Datei eingetragen wird.
Yalu X. schrieb: > Das Problem ist IMHO eher eine falsche Erwartungshaltung des Nutzers. Der unvoreingenommene Benutzer erwartet als Erstelldatum das Datum, wann das Doc oder Bild oder was auch immer erstellt und nicht kopiert, heruntergeladen oder sonst was wurde. Ich finde diese Erwartungshaltung durchaus angemessen. > Mich hat das ehrlich gesagt noch nie gestört. Mich auch nicht, weil ich weiß daß sich das immer auf das Dateisystem bezieht. Trotzdem wäre es schön wenn es so etwas gäbe (und auch korrekt funktionieren würde).
Yalu X. schrieb: > Andreas B. schrieb: >> Yalu X. schrieb: >>> Beim Kopieren einer Datei wird eine neue Datei >>> erstellt, deswegen bekommt diese auch ein neues Dateierstelldatum. >> >> Genau das ist eben das Problem. > > Das Problem ist IMHO eher eine falsche Erwartungshaltung des Nutzers. > Mich hat das ehrlich gesagt noch nie gestört. Ich finde die Erwartungshaltung richtig. Wenn ich eine Datei erzeuge und danach wo anders hin kopiere, interessiert mich am Ende in der Regel nicht, wann ich die Datei kopiert habe, sondern wann sie ursprünglich erstellt wurde. Wie sieht es beim Verschieben statt Kopieren aus? > Ein aus meiner Sicht größeres Problem ist die oft unterschiedliche > Behandlung des Änderungsdatums durch verschiedene Anwendungen. Manche > Anwendungen betrachten das Erstellen einer Datei gleichzeitig auch als > Änderung, andere hingegen nicht. Welches Änderungsdatum hat sie denn dann? Vor der Erstellung gab's ja noch keins.
Andreas B. schrieb: > Ich finde diese Erwartungshaltung durchaus angemessen. Sie ist aber nicht wirklich realisierbar: natürlich will ich von meinen Fotos wissen, wann ich sie aufgenommen habe, was in den EXIF/IPCC-Daten vermerkt ist. Im Filesystem kann das schon rein logisch nicht bewahrt werden, wenn ich die Fotos z.B. von Raw in TIFF und/oder in JPEG wandle, das sind selbstverständlich jeweils neu erstellte Dateien. Übrigens zeigt der Windows-Explorer dieses Aufnahmedatum an, auch wenn das manche hier für "unseriös" halten. Wer im Glashaus sitzt... Georg
Rolf M. schrieb: > Wie sieht es beim Verschieben statt Kopieren aus? Das kommt darauf an... Z.B. davon, ob es innerhalb eines Filesystems passiert oder über Filesystemgrenzen hinweg. Es kann aber auch vom Filesystem selber abhängen und von den ACLs des Zielverzeichnisses. Und von den Rechten des Nutzers. Sprich: eine allgemein gültige Regel gibt es nicht, und kann es auch nicht geben. Nur Nichtprogrammierer vermögen das nicht zu erkennen. Und leider auch viele sog. "Programmierer" nicht... Insgesamt kann man wohl sagen: Metadaten sind generell notorisch unzuverlässig. Das betrifft übrigens nicht nur die Zeitstempel, sondern sogar den Dateinamen...
Rolf M. schrieb: > Welches Änderungsdatum hat sie denn dann? Vor der Erstellung gab's ja > noch keins. Der MSDOS-Copy-Befehl bspw. übernimmt das Änderungsdatum von der Originaldatei. Daher kommt ja auch der komische Effekt, dass das Änderungsdatum vor dem Erstelldatum liegen kann. Rolf M. schrieb: > Ich finde die Erwartungshaltung richtig. Ich finde sie deswegen nicht richtig, weil man schon durch einfache Überlegungen feststellen kann, dass ein Erstelldatum, das über beliebige Kopiervorgänge hinweg unverändert bleibt, technisch gar nicht realisierbar ist. Das Kopieren muss sich ja nicht auf ein einzelnes Filesystem beschränken, Kopieren geht auch über Netzwerke und – wenn man den Bogen etwas weiter spannt – auch über nichtdigitale Medien, wie bspw. Papier. Für seinen Faust schrieb Goethe im Jahr 1772 die ersten Wörter. Diese wurden dann irgendwann von einem Schriftsetzer in eine Druckform übertragen und anschließend mehrfach auf Papier gedruckt. Dieser Vorgang wiederholte sich im Lauf der Jahrhunderte mehrfach, bis eines Tages jemand den Text in eine digitale Form (Textdatei) kopiert hat. Aus dieser wurde dann irgendwann eine PDF-Datei erstellt. Bei dieser langen Kette von Kopiervorgängen hat sich zwar jeweils das Medium geändert, der Inhalt blieb aber immer derselbe (sofern den jeweiligen Abschreibern bzw. Abtippern keine Fehler unterlaufen sind). Das Erstelldatum des Texts ist also nach wie vor das Jahr 1772. Ich habe mir nun gerade mal einen Faust als PDF heruntergeladen, um zu sehen, ob als Erstelldatum 1772 angezeigt wird ;-) Nein, das Erstelldatum ist der 25.07.2020. Was anderes habe ich aber auch gar nicht erwartet. Du etwa?
c-hater schrieb: > Rolf M. schrieb: > >> Wie sieht es beim Verschieben statt Kopieren aus? > > Das kommt darauf an... > > Z.B. davon, ob es innerhalb eines Filesystems passiert oder über > Filesystemgrenzen hinweg. Und schon alleine so was ist doch Mist. Aber solche unsinnigen Unterscheidungen macht Microsoft ja gerne. Schon beim Ziehen eines Icons einer Datei mit der Maus muss man höllisch darauf achten, ob Quelle und Ziel im selben Filesystem liegen, weil die ausgeführte Aktion davon abhängig ist. > Es kann aber auch vom Filesystem selber abhängen und von den ACLs des > Zielverzeichnisses. Wenn das Dateisystem das nicht hergibt, geht es natürlich nicht. Das heißt im Umkehrschluss aber nicht, dass man sinnvolle Aktionen auch dort bleiben lässt, wo sie möglich wären. > Und von den Rechten des Nutzers. Gibt es Berechtigungen, die es dem Benutzer erlauben, eine Datei anzulegen, aber nicht das Dateidatum zu setzen? Yalu X. schrieb: > Rolf M. schrieb: >> Ich finde die Erwartungshaltung richtig. > > Ich finde sie deswegen nicht richtig, weil man schon durch einfache > Überlegungen feststellen kann, dass ein Erstelldatum, das über beliebige > Kopiervorgänge hinweg unverändert bleibt, technisch gar nicht > realisierbar ist. Aber beim Änderungsdatum geht das? Meine Erwartungshaltung ist jedenfalls nicht, dass das Änderungsdatum übernommen wird, das Erstelldatum aber nicht. Es ist eben nicht möglich, eine Datei zu ändern, die noch gar nicht existiert. Deshalb sollte logisch betrachtet auch das Änderungsdatum nicht älter sein als das Erstellungsdatum. > Das Kopieren muss sich ja nicht auf ein einzelnes Filesystem beschränken, > Kopieren geht auch über Netzwerke und – wenn man den Bogen etwas weiter > spannt – auch über nichtdigitale Medien, wie bspw. Papier. Dabei werden die Daten aber auch im Format konvertiert. Das ist dann eine neue Datei. Ich spreche nur vom Kopieren in dem Sinne, dass die Kopie bit für bit exakt dem Original entspricht. Im übrigen ist "Papier" kein Dateiformat. Es geht ja konkret um Erstellungs- und Änderungsdatum von Dateien in einem Dateisystem, und in einem solchen kann man Papier nicht ablegen.
c-hater schrieb: > Insgesamt kann man wohl sagen: Metadaten sind generell notorisch > unzuverlässig. Das betrifft übrigens nicht nur die Zeitstempel, sondern > sogar den Dateinamen... Und ergänzend noch: auch Krams innerhalb der Datei, wie etwa exif bei Jpeg kann natürlich beim "Kopier"vorgang beliebig manipuliert werden. Man kann also nichtmal diesem Zeug wirklich vertrauen.
c-hater schrieb: > Man kann also nichtmal diesem Zeug wirklich vertrauen. Das ist trivial, gefälschte Fotos gibt es so lange wie es überhaupt Fotos gibt. Meiner Meinung nach ist das Aufnahmedatum eines (Original-)Fotos etwas was man nicht ändern dürfte, aber das ist nur meine Meinung. Man kann natürlich ohne grossen Aufwand ein Foto von den Zuständen in der Tönnies-Schlachterei so manipulieren, dass das Datum vor der Corona-Krise liegt - so ohne weiteres ist das sicher nicht einmal strafbar, erst wenn man versucht damit z.B. Prozessbetrug zu begehen. Georg
Rolf M. schrieb: > Yalu X. schrieb: >> Rolf M. schrieb: >>> Ich finde die Erwartungshaltung richtig. >> >> Ich finde sie deswegen nicht richtig, weil man schon durch einfache >> Überlegungen feststellen kann, dass ein Erstelldatum, das über beliebige >> Kopiervorgänge hinweg unverändert bleibt, technisch gar nicht >> realisierbar ist. > > Aber beim Änderungsdatum geht das? Nein, natürlich. Wie ich oben schon schrieb, gibt es beim Änderungsdatum sogar noch mehr Wildwuchs als beim Erstelldatum: Yalu X. schrieb: > Ein aus meiner Sicht größeres Problem ist die oft unterschiedliche > Behandlung des Änderungsdatums durch verschiedene Anwendungen. Rolf M. schrieb: > Meine Erwartungshaltung ist jedenfalls nicht, dass das Änderungsdatum > übernommen wird, das Erstelldatum aber nicht. Meine auch nicht. Es kann zwar mitunter ganz praktisch sein, wenn das Änderungsdatum beim Kopieren beibehalten wird, allerdings nur in den relativ seltenen Fällen, wo man genau weiß, wie die Dateien entstanden sind, weil man sonst das Änderungsdatum nicht richtig interpretieren kann.
georg schrieb: > c-hater schrieb: >> Man kann also nichtmal diesem Zeug wirklich vertrauen. > > Das ist trivial, gefälschte Fotos gibt es so lange wie es überhaupt > Fotos gibt. Meiner Meinung nach ist das Aufnahmedatum eines > (Original-)Fotos etwas was man nicht ändern dürfte, aber das ist nur > meine Meinung. Hier sehe ich dann tatsächlich eine falsche Erwartungshaltung. Diese Daten sind kein rechtsgültiges Dokument, sondern einfach nur Infos, die man dazu geben kann. Das ist ungefähr so, wie wenn man ein Papierfoto macht und nachher mit Kuli auf die Rückseite das Datum der Aufnahme drauf schreibt. Übrigens: Was ist, wenn die Uhr der Kamera bei der Aufnahme verstellt war? Würdest du es auch verpflichtend machen, dass man vor jedem Foto erst sicherstellen muss, dass die Uhrzeit der Kamera auch korrekt eingestellt ist? Man kann natürlich ohne grossen Aufwand ein Foto von den > Zuständen in der Tönnies-Schlachterei so manipulieren, dass das Datum > vor der Corona-Krise liegt - so ohne weiteres ist das sicher nicht > einmal strafbar, erst wenn man versucht damit z.B. Prozessbetrug zu > begehen. Ich glaube nicht, dass solche Daten vor Gericht überhaupt als Beweismittel anerkannt sind.
Yalu X. schrieb: > Ich finde sie deswegen nicht richtig, weil man schon durch einfache > Überlegungen feststellen kann, dass ein Erstelldatum, das über beliebige > Kopiervorgänge hinweg unverändert bleibt, technisch gar nicht > realisierbar ist. Das würde ich so nicht stehen lassen. Wenn das Fileformat nicht geändert wird, spricht nichts dagegen, das Erstellungsdatum als das was es ist, nämlich die Zeit der Erstellung, festzuhalten. Wenn man das Medium oder das Format ändert, ist das nicht vergleichbar. Insofern, was Goethe betrifft: Äpfel und Birnen.
Rolf M. schrieb: > Würdest du es auch verpflichtend machen, dass man vor jedem Foto > erst sicherstellen muss, dass die Uhrzeit der Kamera auch korrekt > eingestellt ist? Ich meine das auch nicht als Verpflichtung mit Sanktionen, sondern es ist mein eigenes Interesse. Irgendwie fehlt mir die Fantasie mir einen vernünftigen Grund auszudenken, warum ich meine Fotos aus dem Urlaub von 2018 auf 2020 umdatieren sollte, solange ich nicht jemanden damit täuschen will. Es gibt hier im Forum aber auch ganz andere Meinungen dazu. Wie gesagt, ist nur meine. Georg
Rolf M. schrieb: > c-hater schrieb: >> Das kommt darauf an... >> >> Z.B. davon, ob es innerhalb eines Filesystems passiert oder über >> Filesystemgrenzen hinweg. > > Und schon alleine so was ist doch Mist. Aber solche unsinnigen > Unterscheidungen macht Microsoft ja gerne. Setz' einfach mal deine verdammte Fanboy-Brille ab. Auch unixiode OS machen da natürlich Unterschiede. Es bleibt ihnen garnix anderes übrig, schließlich ist nicht gesichert, dass das Zieldateisystem unter Kontrolle des lokalen Kernels steht. Ich könnte ausrasten bei diesen typischen Fanboy-Postings.
c-hater schrieb: >> Und schon alleine so was ist doch Mist. Aber solche unsinnigen >> Unterscheidungen macht Microsoft ja gerne. > > Setz' einfach mal deine verdammte Fanboy-Brille ab. Auch unixiode OS > machen da natürlich Unterschiede. Was es mit "Fanboy" zu tun hat, wenn man eine bestimmte Funktionalität eines bestimmten Systems kritisiert, ist mir unklar. Vielmehr scheinst du hier der Fanboy zu sein, der gekränkt ist, weil sein geliebtes System kritisiert wurde. > Es bleibt ihnen garnix anderes übrig, schließlich ist nicht gesichert, > dass das Zieldateisystem unter Kontrolle des lokalen Kernels steht. Lerne erst mal lesen, bevor du irgendwelche "Fanboy"-Unterstellungen machst. Ich hatte dazu bereits was geschrieben: Rolf M. schrieb: > Wenn das Dateisystem das nicht hergibt, geht es natürlich nicht. Das > heißt im Umkehrschluss aber nicht, dass man sinnvolle Aktionen auch dort > bleiben lässt, wo sie möglich wären. > Ich könnte ausrasten bei diesen typischen Fanboy-Postings. Dito.
Rolf M. schrieb: > c-hater schrieb: >>> Und schon alleine so was ist doch Mist. Aber solche unsinnigen >>> Unterscheidungen macht Microsoft ja gerne. >> >> Setz' einfach mal deine verdammte Fanboy-Brille ab. Auch unixiode OS >> machen da natürlich Unterschiede. > > Was es mit "Fanboy" zu tun hat, wenn man eine bestimmte Funktionalität > eines bestimmten Systems kritisiert, ist mir unklar. Vielmehr scheinst > du hier der Fanboy zu sein, der gekränkt ist, weil sein geliebtes System > kritisiert wurde. Nein, er hat vollkommen Recht. Auch unter unixoiden System wird unterschieden, ob man innerhalb eines Filesystems verschiebt (-> rename) oder über Filesystemsgrenzen hinweg (-> copy&delete). Das sollte eigentlich jeder Entwickler wissen, da es andere semantische Unterschiede dabei gibt, z.B. ist die das Umbenennen innerhalb eines Filesystems eine atomare Operation, das Kopieren in ein anderes Filesystem mit anschliessendem Löschen des Originals dagegen nicht. Also nix Fanboy sondern nur Richtigstellung einer Fehlannahme - nämlich dass nur Microsoft das so handhabt während das AFAIK alle Betriebssysteme so machen (weil es eben aus praktischen Gründen schlecht anders geht).
Ralf D. schrieb: > Das sollte eigentlich jeder Entwickler wissen, da es andere semantische > Unterschiede dabei gibt, z.B. ist die das Umbenennen innerhalb eines > Filesystems eine atomare Operation, das Kopieren in ein anderes > Filesystem mit anschliessendem Löschen des Originals dagegen nicht. Und was hat das jetzt mit der Übernahme des Erstellungsdatums beim Verschieben zu tun? Darum ging es schließlich, und nicht um die Frage, ob die Verschiebeoperation selbst atomar ist oder nicht.
Rolf M. schrieb: > Ralf D. schrieb: >> Das sollte eigentlich jeder Entwickler wissen, da es andere semantische >> Unterschiede dabei gibt, z.B. ist die das Umbenennen innerhalb eines >> Filesystems eine atomare Operation, das Kopieren in ein anderes >> Filesystem mit anschliessendem Löschen des Originals dagegen nicht. > > Und was hat das jetzt mit der Übernahme des Erstellungsdatums beim > Verschieben zu tun? Darum ging es schließlich, und nicht um die Frage, > ob die Verschiebeoperation selbst atomar ist oder nicht. Es ging darum, dass die Übernahme von bestimmten Attributen eben nicht trivial ist und dass man da schon etwas genauer wissen sollte, was da passiert. In der realen Welt macht es auch einen Unterschied, ob ich eine Akte von einem Büro in ein anderes trage oder sie per Fax an einen anderen Ort (Äquivalenz zum anderen Filesystem) kopiere und damit eine neue Verkörperung der Daten produziere, die dann natürlich implizit den Kopierzeitpunkt als Erstellungszeitpunkt der Verkörperung (nicht der Informationen) haben. Die Metadaten im Filesystem beziehen sich originär (also auf OS-Level) nur auf die Verkörperung der Daten in der Datei, eine Übertragung bei Erstelung von Kopien erfolgt auf Applikationsebene - und da hängt es eben von der Semantikdefinition in der Applikation ab, was da passiert. Alles ganz logisch und offensichtlich, wenn man weit genug runter auf die Spezifikation und Implementierung schaut. Und komplett losgelöst von irgendwelchen Erwartungen irgendwelcher Anwender, denen niemand die Bedeutung dieser Daten beigebracht hat.
Ralf D. schrieb: > Und komplett losgelöst von > irgendwelchen Erwartungen irgendwelcher Anwender Naja, andrerseits erwartet man auch nicht dass Captain Kirk nach dem Beamen auf einen Planeten neugeboren ist... Georg
georg schrieb: > Ralf D. schrieb: >> Und komplett losgelöst von >> irgendwelchen Erwartungen irgendwelcher Anwender > > Naja, andrerseits erwartet man auch nicht dass Captain Kirk nach dem > Beamen auf einen Planeten neugeboren ist... Oh, das wäre eine interessante Betrachtung. Der Inhalt des Captains (Makro-Zustand von Körper und "Geist") ist sicherlich erwartungsgemäß unverändert (wenn der Transporter keine Fehlfunktion hat ...), aber was ist auf Zellebene? Sind das frische Zellen (der Körper regeneriert sich ja auch so ständig) oder werden da gealterte Zellen erzeugt? Du musst nur auf die richtige Ebene heruntergehen, dann wird das sehr interessant. :-)
Ralf D. schrieb: > georg schrieb: >> Ralf D. schrieb: >>> Und komplett losgelöst von >>> irgendwelchen Erwartungen irgendwelcher Anwender >> >> Naja, andrerseits erwartet man auch nicht dass Captain Kirk nach dem >> Beamen auf einen Planeten neugeboren ist... > > Oh, das wäre eine interessante Betrachtung. Allerdings eine alte. Das wurde schon vor 20 Jahren bis zum Erbrechen in irgendwelchen Star-Trek-Newsgroups diskutiert. Der Inhalt des Captains > (Makro-Zustand von Körper und "Geist") ist sicherlich erwartungsgemäß > unverändert (wenn der Transporter keine Fehlfunktion hat ...), Genau. Das wäre zwar nach Heisenberg nicht möglich, aber deshalb gibt's ja den Heisenberg-Kompensator. https://de.wikipedia.org/wiki/Star-Trek-Technologie#Heisenberg-Kompensator > aber was ist auf Zellebene? Sind das frische Zellen (der Körper regeneriert > sich ja auch so ständig) oder werden da gealterte Zellen erzeugt? Das geht in Richtung Schiff des Theseus. Wenn ich an einem Schiff jedes Teil einzeln durch ein neues ersetze, bis alle Teile (oder zumindest die meisten) neu sind, ist es dann überhaupt noch das selbe Schiff? https://de.wikipedia.org/wiki/Schiff_des_Theseus
Rolf M. schrieb: > Allerdings eine alte. Das wurde schon vor 20 Jahren bis zum Erbrechen in > irgendwelchen Star-Trek-Newsgroups diskutiert. Und in StarTrek selbst wird auch schon öfters thematisiert. Es gibt Folgen da gibt es nach dem Beamen die Person 2 mal, mit allen ethischen Fragen die das aufwirft. Das Thema ist nun wirklich so überhaupt nicht neu. Rolf M. schrieb: > Das geht in Richtung Schiff des Theseus. Wenn ich an einem Schiff jedes > Teil einzeln durch ein neues ersetze, bis alle Teile (oder zumindest die > meisten) neu sind, ist es dann überhaupt noch das selbe Schiff? Die Frage ist doch dank Fahrgestellnummer an KFZ längst gelöst. Das Fahrgestell definiert das Fahrzeug. Alles andere ist Zubehör. Der Antike fehlte wohl der Geist unseres Kraftfahrtbundesamtes. Gibts auch für Waffen. Die Nummer steht auf dem Verschluss. Dieser IST die Waffe. Alles andere sind Anbauteile. Beim Menschen übrigens ist dies das zentrale Nervensystem. Hautzellen, Blutzellen und ein paar Andre, erneuern sich regelmäßig. Zellen des ZNS aber nicht. Auch nicht die Zellen der inneren Organe. Daher ist es auch Humbug dass der gesamte Mensch regelmäßig ersetzt werden würde. Das sieht man auch daran dass tote Hirnzellen nicht mehr ersetzt werden können (vgl. Winnie)
:
Bearbeitet durch User
Cyblord -. schrieb: > Das > Fahrgestell definiert das Fahrzeug. Alles andere ist Zubehör. also Nummer raus flexen und es ist nicht mehr mein Bier, wenn die Karre am Bach gammelt :-] Hatten die Griechen schon Seriennummern an ihren Trieren?
● J-A V. schrieb: > also Nummer raus flexen und es ist nicht mehr mein Bier, > wenn die Karre am Bach gammelt Da bist du nicht der Erste der auf diese Idee kommt. Aber Achtung, die Nummer ist meist zweimal vorhanden. Und, wie ich aus diversen Krimifilmen weiß, kann man rausgefeilte Seriennummern mit moderner Technik wieder sichtbar machen. Was bei Waffen klappt sollte auch beim Auto klappen.
Cyblord -. schrieb: > ● J-A V. schrieb: >> also Nummer raus flexen und es ist nicht mehr mein Bier, >> wenn die Karre am Bach gammelt > > Da bist du nicht der Erste der auf diese Idee kommt. > > Aber Achtung, die Nummer ist meist zweimal vorhanden. Sie ist meistens mehr als zweimal vorhanden. Zum Beispiel wird sie in der Regel auch Teil der Buskommunikation im Fahrzeug sein. > Und, wie ich aus diversen Krimifilmen weiß, kann man rausgefeilte > Seriennummern mit moderner Technik wieder sichtbar machen. Die werden nicht runtergefeilt, sondern es wird einfach das Metall um die FIN herum großzügig ausgeschnitten und dann ein neues Stück reingeschweißt. Die Technik, die das wieder sichtbar macht, will ich sehen. Die ist vermutlich auf dem gleichen Niveau wie die FBI-Software, die aus drei Pixeln ein hochaufgelöstes Bild eines Gesichts rekonstruieren kann.
:
Bearbeitet durch User
Bleibt doch einfach beim Alltag, Haltbarkeitsdaten von gewissen Produkten kann ich immer schwieriger identifizieren. Kaufbelege für Hardware besser in Schutzfolie aufheben, sonst bleicht die Farbe aus oder verschwindet völlig. Im Fernsehen kann man glaube ich auch ohne Leertaste Texte tippen oder einen von Ansteckungsraten da noch und da noch und da noch.. (huch wie furchtbar) erzählen ohne jegliche äußere (unterscheidbare) Krankheitsbelege. Neulich wollte ich was (per Mausmarkierung) aus dem Hexeditor (Ghex z.B.) kopieren, um weiter zu posten - normalerweise nimmt man für sowas (Zwischenablage) Notepad. Was geht in dieser Hinsicht bei Linux genauso problemlos? (Habe ich letztendlich in der Konsole (glaube ich) gemacht. Der Desktop-Editor (obwohl Programmiereditor) ging nicht - bzw. hab ich die nötige Umstellung auf die Schnelle nicht gefunden. Wenn man Schadsofware im System hat, dann ist auf alle Fälle das Erstelldatum interessant. Bei Unix war früher wohl auch eher Zeitmessung vorrangig, wegen der teuren Rechenzeitberechnung.
rbx schrieb: > Bleibt doch einfach beim Alltag, Haltbarkeitsdaten von gewissen > Produkten kann ich immer schwieriger identifizieren. Fielmann? > Kaufbelege für > Hardware besser in Schutzfolie aufheben, sonst bleicht die Farbe aus > oder verschwindet völlig. Die meisten "Kaufbelege" ich nenne sie mal Rechnungen habe ich so oder so online, weil ich online kaufe. Was ich an Papier bekomme wird sofort gescant. > > Im Fernsehen kann man glaube ich auch ohne Leertaste Texte tippen oder > einen von Ansteckungsraten da noch und da noch und da noch.. (huch wie > furchtbar) erzählen ohne jegliche äußere (unterscheidbare) > Krankheitsbelege. Würr?
:
Bearbeitet durch User
rbx schrieb: > Kaufbelege für > Hardware besser in Schutzfolie aufheben, sonst bleicht die Farbe aus > oder verschwindet völlig. hehe und dann reagiert das mit der Folie, die ansonsten chemikalienresistent ist. Aber die Weichmacher in den Thermoausdrucken lösen auch DAS an...
● J-A V. schrieb: > hehe und dann reagiert das mit der Folie, > die ansonsten chemikalienresistent ist. > Aber die Weichmacher in den Thermoausdrucken lösen auch DAS an... Und teilweise ist das auch noch egal, wenn die Geräte gleich nach 2-jähriger Garantiezeit kaputtgehen - oder wenn die Garantiezeit länger ist, aber die Erstatzteilsituation nicht mehr so toll ist. (alles fließt.. https://de.wikipedia.org/wiki/Panta_rhei ) ;)
rbx schrieb: > Wenn man Schadsofware im System hat, dann ist auf alle Fälle das > Erstelldatum interessant Klar, weil die Schadsoftware sich ja sklavisch an alle Regeln hält. Es ist wohl eher so dass du da garkeine Datei findest. Georg
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.