Forum: PC Hard- und Software mir fehlt das "erstellt".


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von ● J-A V. (Firma: FULL PALATINSK) (desinfector) Benutzerseite


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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...

von oszi40 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
● J-A V. schrieb:
> diese Anzeige -?

ls -? sollte alle Möglichkeiten zeigen.
(Kommt allerdings auch etwas auf das Dateisystem an.)

von ● J-A V. (Firma: FULL PALATINSK) (desinfector) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Ich bin da nicht im Terminalfenster.

von Le X. (lex_91)


Bewertung
0 lesenswert
nicht lesenswert
● 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
von ● J-A V. (Firma: FULL PALATINSK) (desinfector) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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_°

von Le X. (lex_91)


Bewertung
0 lesenswert
nicht lesenswert
● 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.

von h4x0r! (Gast)


Bewertung
0 lesenswert
nicht lesenswert
● J-A V. schrieb:
> BTW, wenn ich diese Anzeige habe,
> kann ich keinen Screenshot machen.

DRUCK-Taste benutzt?

von ● J-A V. (Firma: FULL PALATINSK) (desinfector) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
h4x0r! schrieb:
> ● J-A V. schrieb:
>> BTW, wenn ich diese Anzeige habe,
>> kann ich keinen Screenshot machen.
>
> DRUCK-Taste benutzt?

öh... ja

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
● 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.

von Cyblord -. (cyblord)


Bewertung
-15 lesenswert
nicht lesenswert
Was für ein unseriöses Betriebssystem soll denn das sein? Ein 
Frickel-Linux oder ein Hipster-Mac? Nutz halt mal ordentliche Dinge.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
7 lesenswert
nicht lesenswert
Cyblord-OS wird's wohl nicht sein.

von ● J-A V. (Firma: FULL PALATINSK) (desinfector) Benutzerseite


Bewertung
3 lesenswert
nicht lesenswert
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
von npn (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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!

von Cyblord -. (cyblord)


Bewertung
-9 lesenswert
nicht lesenswert
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.

von npn (Gast)


Bewertung
2 lesenswert
nicht lesenswert
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.

von ● J-A V. (Firma: FULL PALATINSK) (desinfector) Benutzerseite


Bewertung
3 lesenswert
nicht lesenswert
Wir können gerne über meine unzureichenden Linux-Kenntnisse witzeln.

Aber einen Flamewar über das "richtige" OS brauchen wir nicht.

von Cyblord -. (cyblord)


Bewertung
-6 lesenswert
nicht lesenswert
npn schrieb:
> Lesen kannst du auch nicht?

Texte zu Unseriösen Dingen werden bei mir automatisch ausgeblendet. Lag 
wohl daran.

von npn (Gast)


Bewertung
0 lesenswert
nicht lesenswert
● 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--

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
5 lesenswert
nicht lesenswert
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.

von Cyblord -. (cyblord)


Bewertung
-7 lesenswert
nicht lesenswert
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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
5 lesenswert
nicht lesenswert
Cyblord -. schrieb:
> ich habe bereits in meinem ersten Post eine Lösung präsentiert.

Eine Lösung?

Sorry, ich sehe nur FUD.

von wendelsberg (Gast)


Bewertung
2 lesenswert
nicht lesenswert
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

von zitter_ned_aso (Gast)


Bewertung
0 lesenswert
nicht lesenswert
● 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.))

von Heiner (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Diese Information gibt es schlicht nicht.

Doch, ext4 hat das, wie schon weiter oben von lex_91 festgestellt:
# 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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Heiner (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Gleiches gilt übrigens für ZFS, mit der Ausnahme, dass (mindestens) 
FreeBSD hier eine private Erweiterung für stat(2) implementiert hat, 
st_birthtim.
     The time-related fields of struct stat are as follows:

     st_atim          Time when file data last accessed.  Changed by the
                      mknod(2), utimes(2), read(2) and readv(2) system calls.

     st_mtim          Time when file data last modified.  Changed by the
                      mkdir(2), mkfifo(2), mknod(2), utimes(2), write(2) and
                      writev(2) system calls.

     st_ctim          Time when file status was last changed (inode data
                      modification).  Changed by the chflags(2), chmod(2),
                      chown(2), creat(2), link(2), mkdir(2), mkfifo(2),
                      mknod(2), rename(2), rmdir(2), symlink(2), truncate(2),
                      unlink(2), utimes(2), write(2) and writev(2) system
                      calls.

     st_birthtim      Time when the inode was created.

     The following time-related macros are defined for compatibility:

     #define st_atime                st_atim.tv_sec
     #define st_mtime                st_mtim.tv_sec
     #define st_ctime                st_ctim.tv_sec
     #ifndef _POSIX_SOURCE
     #define st_birthtime            st_birthtim.tv_sec
     #endif

Weiß nicht, ob's die unter Solaris auch gibt.

von Heiner (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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/

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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).

von sid (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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

von Andreas B. (bitverdreher)


Bewertung
0 lesenswert
nicht lesenswert
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?

von c-hater (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Andreas B. (bitverdreher)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Le X. (lex_91)


Bewertung
0 lesenswert
nicht lesenswert
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).

von Yalu X. (yalu) (Moderator)


Bewertung
2 lesenswert
nicht lesenswert
Posix unterstützt zwar nur atime, mtime und ctime, in Linux gibt es aber
zusätzlich noch btime, was über statx() abgefragt werden kann:

int statx(int dirfd, const char *pathname, int flags,
          unsigned int mask, struct statx *statxbuf);

struct statx {
    ...
    /* The following fields are file timestamps */
    struct statx_timestamp stx_atime;  /* Last access */
    struct statx_timestamp stx_btime;  /* Creation */
    struct statx_timestamp stx_ctime;  /* Last status change */
    struct statx_timestamp stx_mtime;  /* Last modification */
    ...
};

Auch die Kommandos stat und ls unterstützen die Birthtime:

$ stat myfile 
  File: myfile
  Size: 0               Blocks: 0          IO Block: 4096   regular empty file
Device: 803h/2051d      Inode: 80778808    Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/      me)   Gid: ( 1000/      me)
Access: 2020-07-23 09:29:09.456625050 +0200
Modify: 2020-07-23 09:27:44.122227198 +0200
Change: 2020-07-23 09:28:16.789302609 +0200
 Birth: 2020-07-23 09:25:16.747027376 +0200

$ ls -l --time birth myfile 
-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
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von georg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von 🐧 DPA 🐧 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Programmierer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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>").

von 🐧 DPA 🐧 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
🐧 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.

von DPA (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hatte FreeBSD denn schonmal eine Version von stat ohne st_birthtim?

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von c-hater (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
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...

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von c-hater (Gast)


Angehängte Dateien:

Bewertung
-2 lesenswert
nicht lesenswert
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...

von Cyblord -. (cyblord)


Bewertung
-2 lesenswert
nicht lesenswert
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.

von Rolf M. (rmagnus)


Angehängte Dateien:

Bewertung
-1 lesenswert
nicht lesenswert
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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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 
…

von Cyblord -. (cyblord)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von ● J-A V. (Firma: FULL PALATINSK) (desinfector) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Aber immerhin HATTE es den Balken.

Ich liebe ja nichts mehr als irgendwelche Funktionen ohne 
Fortschrittsanzeige.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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.

von Rolf M. (rmagnus)


Bewertung
0 lesenswert
nicht lesenswert
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.
von Le X. (lex_91)


Bewertung
1 lesenswert
nicht lesenswert
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
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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. ;-)

von guest (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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."

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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. ;-)

von Rolf M. (rmagnus)


Bewertung
0 lesenswert
nicht lesenswert
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.

von guest (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Andreas B. (bitverdreher)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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!

von c-hater (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
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...

von Yalu X. (yalu) (Moderator)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Andreas B. (bitverdreher)


Bewertung
0 lesenswert
nicht lesenswert
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).

von Yalu X. (yalu) (Moderator)


Bewertung
0 lesenswert
nicht lesenswert
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
von Andreas B. (bitverdreher)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Yalu X. (yalu) (Moderator)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Andreas B. (bitverdreher)


Bewertung
0 lesenswert
nicht lesenswert
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).

von Rolf M. (rmagnus)


Bewertung
0 lesenswert
nicht lesenswert
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.

von georg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von c-hater (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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...

von Yalu X. (yalu) (Moderator)


Bewertung
1 lesenswert
nicht lesenswert
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?

von Rolf M. (rmagnus)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von c-hater (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von georg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Yalu X. (yalu) (Moderator)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Rolf M. (rmagnus)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Andreas B. (bitverdreher)


Bewertung
0 lesenswert
nicht lesenswert
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.

von georg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von c-hater (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Rolf M. (rmagnus)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Ralf D. (doeblitz)


Bewertung
0 lesenswert
nicht lesenswert
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).

von Rolf M. (rmagnus)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Ralf D. (doeblitz)


Bewertung
0 lesenswert
nicht lesenswert
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.

von georg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Ralf D. (doeblitz)


Bewertung
0 lesenswert
nicht lesenswert
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. :-)

von Rolf M. (rmagnus)


Bewertung
1 lesenswert
nicht lesenswert
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

von Cyblord -. (cyblord)


Bewertung
-1 lesenswert
nicht lesenswert
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
von ● J-A V. (Firma: FULL PALATINSK) (desinfector) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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?

von Cyblord -. (cyblord)


Bewertung
-1 lesenswert
nicht lesenswert
● 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.

von Rolf M. (rmagnus)


Bewertung
0 lesenswert
nicht lesenswert
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
von rbx (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
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.

von Cyblord -. (cyblord)


Bewertung
-1 lesenswert
nicht lesenswert
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
von ● J-A V. (Firma: FULL PALATINSK) (desinfector) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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...

von rbx (Gast)


Bewertung
0 lesenswert
nicht lesenswert
● 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 ) ;)

von georg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.