Inkonsistente Ausgabe von ls

[Andreas Kohlbach]

Folgendes im Verzeichnis meines lokalen Webservers (tritt aber auch sonst
auf):

-rw-r--r-- 1 ank ank 201 Jan 17 2022 datei0.php
-rw-r--r-- 1 ank ank 4160 Jan 17 2022 datei1.php
-rw-r--r-- 1 ank ank 16248 Jan 17 2022 datei2.php
drwxr-xr-x 3 ank ank 4096 Jun 21 22:50 datei3.php
-rw-r--r-- 1 ank ank 51831 Jun 22 00:33 datei4.php
-rw-r--r-- 1 ank ank 7263 Jun 24 20:00 datei5.php

Sollte das Jahr bei "ls" (ohne Parameter) nicht nur dann angegeben
werden, wenn das Datum älter als ein Jahr ist (also auf heute bezogen der
22. 9.2021)?

Es sei angemerkt, dass die Dateien, die den 17. Januar dieses Jahres als
Datum tragen von einem anderen Rechner per scp kopiert wurden.
--
Andreas

[Marco Moock]

Am 23.09.2022 um 14:25:29 Uhr schrieb Andreas Kohlbach:

> Sollte das Jahr bei "ls" (ohne Parameter) nicht nur dann angegeben
> werden, wenn das Datum älter als ein Jahr ist (also auf heute bezogen
> der 22. 9.2021)?

ls ohne Parameter gibt gar kein Datum aus, nur die Dateinamen.

ls -l gibt bei Kram vom Vorjahr das Jahr, aber keine Uhrzeit aus.

-rw-rw-r-- 1 m m 85 Sep 23 07:10 todo
-rw-rw-r-- 1 m m 127 Dez 20 2021 tor

Das war unter Ubuntu 22.04.

[Andreas Karrer]

* Andreas Kohlbach <a...@spamfence.net>:

> On Fri, 23 Sep 2022 20:48:25 +0200, Marco Moock wrote:
>>
>> Am 23.09.2022 um 14:25:29 Uhr schrieb Andreas Kohlbach:
>>
>>> Sollte das Jahr bei "ls" (ohne Parameter) nicht nur dann angegeben
>>> werden, wenn das Datum älter als ein Jahr ist (also auf heute bezogen
>>> der 22. 9.2021)?

älter als ein *halbes* Jahr. War "schon immmer" so, also sicher seit
1980, und ist dokumentiert:
https://www.gnu.org/software/coreutils/manual/html_node/Formatting-file-timestamps.html


> Unbuntu ist ja auch "nur" Debian.
>
> Hat jemand auf einem Rechner vielleicht Dateien vor September 2021, und
> könnte diese per SCP als Gegenprobe mal auf einen anderen Rechner kopieren?

Es ist egal, woher die Datei kommt. Unix speichert die folgenden Zeiten:

atime /* Time of last access */
mtime /* Time of last modification */
ctime /* Time of last status change */

Und nein, ctime ist NICHT die "creation time", eine solche speichert
Unix nicht, sondern die time of last file metadata change. Also z.B.
die Zeit, als die Datei in das aktuelle Verzeichnis verschoben wurde,
umbenannt wurde, die Permission Bits geändert wurden und so.

atime und mtime kann man mit "touch" (bzw. utime()) verändern, ctime
nicht. Wenn du also eine "Datei vor September 2021" willst:

touch -d 2021-08-31 foobarbaz

- Andi

[Tim Ritberg]

Am 23.09.22 um 22:35 schrieb Andreas Karrer:

> Und nein, ctime ist NICHT die "creation time", eine solche speichert
> Unix nicht, sondern die time of last file metadata change.

Ja, nein!
Heisst birth bei ext4 ;-)

Tim

[Ulli Horlacher]

Andreas Kohlbach <a...@spamfence.net> wrote:
> Folgendes im Verzeichnis meines lokalen Webservers (tritt aber auch sonst
> auf):
>
> -rw-r--r-- 1 ank ank 201 Jan 17 2022 datei0.php
> -rw-r--r-- 1 ank ank 4160 Jan 17 2022 datei1.php
> -rw-r--r-- 1 ank ank 16248 Jan 17 2022 datei2.php
> drwxr-xr-x 3 ank ank 4096 Jun 21 22:50 datei3.php
> -rw-r--r-- 1 ank ank 51831 Jun 22 00:33 datei4.php
> -rw-r--r-- 1 ank ank 7263 Jun 24 20:00 datei5.php

Nimm
ls -l --time-style=+"%Y-%m-%d %H:%M:%S"
dann stellt sich die Frage erst gar nicht.

--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: horl...@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: http://www.tik.uni-stuttgart.de/

[Enrik Berkhan]

Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
> Andreas Kohlbach <a...@spamfence.net> wrote:
>> Folgendes im Verzeichnis meines lokalen Webservers (tritt aber auch sonst
>> auf):
>>
>> -rw-r--r-- 1 ank ank 201 Jan 17 2022 datei0.php
>> -rw-r--r-- 1 ank ank 4160 Jan 17 2022 datei1.php
>> -rw-r--r-- 1 ank ank 16248 Jan 17 2022 datei2.php
>> drwxr-xr-x 3 ank ank 4096 Jun 21 22:50 datei3.php
>> -rw-r--r-- 1 ank ank 51831 Jun 22 00:33 datei4.php
>> -rw-r--r-- 1 ank ank 7263 Jun 24 20:00 datei5.php
>
> Nimm
> ls -l --time-style=+"%Y-%m-%d %H:%M:%S"
> dann stellt sich die Frage erst gar nicht.

ls -l --time-style='+%F %T'

spart soooo viiiiiel Tipparbeit ...

oder:

ls -l --time-style='+%FT%T%z'

dann sieht man (hier) sogar, ob der Zeitstempel aus dem Sommer oder aus
dem Winter ist ;-)

[Ulli Horlacher]

Enrik Berkhan <Enrik....@inka.de> wrote:

>> ls -l --time-style=+"%Y-%m-%d %H:%M:%S"
>

> ls -l --time-style='+%F %T'
>
> spart soooo viiiiiel Tipparbeit ...

Wer das staendig eintippt und das Konzept der Aliase nicht verstanden hat,
der hat es nicht besser verdient :-)

[Andreas Karrer]

* Tim Ritberg <t...@server.invalid>:

In der Tat. Und nicht nur da.

Da hat sich in den letzten Jahren was getan, das mir altem Knacker
nicht bewusst war.

ext4 und ein paar andere Filesysteme können die "birth time" speichern,
und bei genügend neuen Kernels tun das die entsprechenden Syscalls
auch. In der statx-Struktur heisst das entsprechende Feld "stx_btime":

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 */

Mit "stat" kann man sich diese Timestamps ausgeben lassen:

$ stat foobar
...
Access: 2022-09-24 22:32:24.891797628 +0200
Modify: 2022-09-24 22:36:33.437441812 +0200
Change: 2022-09-24 22:37:23.618614456 +0200
Birth: 2022-09-24 22:31:56.447178176 +0200

Auch "ls" hat eine gut versteckte Option dafür (vgl. "ls --help"):

$ ls --time=birth -ln foobar
-rw-r--r-- 1 1000 1000 4 Sep 24 22:31 foobar

Die Semantik und der Wert einer "Birth Time" ist nicht intuitiv klar,
und das war wohl auch ein Grund, warum Ken Thompson darauf verzichtet
hat. Bei aktuellem Linux offenbar so, dass die Birth Time gesetzt wird,
wenn die Datei (der inode) im lokalen Filesystem erzeugt wird. Bei
rename(2) innerhalb des gleichen Filesystems bleibt die btime erhalten,
nicht aber beispielsweise bei "cp -a". Man kann eine Datei also
umbenennen und mit komplett anderem Inhalt überschreiben, aber die
"Birth Time" bleibt erhalten:

$ stat IMG_42345.JPG | grep Birth
Birth: 2022-06-21 14:23:50.275230832 +0200
$ mv IMG_42345.JPG katzenvideo.mp4
$ wget -q -O- https://area51.invalid/videos/cat.mp4 > katzenvideo.mp4
$ stat katzenvideo.mp4 | grep Birth
Birth: 2022-06-21 14:23:50.275230832 +0200

Wie sinnvoll das ist, bleibe dahingestellt.

Da man atime und mtime mit "touch" (bzw. utime()) auf beliebige Werte
setzen kann, kann man Dateien erzeugen, die verändert und gelesen
wurden, bevor es sie gab:

$ touch --date=2022-09-22 glubber
$ touch --date=2022-09-23 -a glubber
$ stat glubber
...
Access: 2022-09-23 00:00:00.000000000 +0200
Modify: 2022-09-22 00:00:00.000000000 +0200
Change: 2022-09-24 23:41:19.264588578 +0200
Birth: 2022-09-24 23:41:13.072418293 +0200




wwg, Andi

[Marc Haber]

Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
>Enrik Berkhan <Enrik....@inka.de> wrote:
>
>>> ls -l --time-style=+"%Y-%m-%d %H:%M:%S"
>>
>> ls -l --time-style='+%F %T'
>>
>> spart soooo viiiiiel Tipparbeit ...
>
>Wer das staendig eintippt und das Konzept der Aliase nicht verstanden hat,
>der hat es nicht besser verdient :-)

Shellaliase haben bei Leuten aus den Operations den Nachteil, dass sie
dort, wo man sie braucht, nie installiert sind. Bei einem Entwickler,
de 90 % seiner Zeit auf dem Arbeitsplatz- und Entwicklungssystem
verbringt und sonst höchstens mal auf eine Handvoll Testkisten
herumrutscht ist das einfacher.

Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[Marcel Mueller]

Am 25.09.22 um 11:09 schrieb Marc Haber:

> Shellaliase haben bei Leuten aus den Operations den Nachteil, dass sie
> dort, wo man sie braucht, nie installiert sind.

Das kann eine kleine Batch lösen, die in einem im persönlichen
Userprofile referenzierten Path liegt, oder aber auf allen betroffenen
Kisten einmal nach /usr/local/bin kopiert wird.


Marcel

[Dietz Proepper]

Das führt dann dazu, dass $jede Box ein klein wenig anders aussieht.

DAS WILLST DU NICHT. GLAUBE MIR! (Zumindest bei mehr als drei
Maschinen.)

Spätestens wenn Du mal 4h debuggt hast, warum sich Node 23 im Cluster
anders verhält als die anderen 42 Maschinen und dann feststellst, dass
die Individualconfig auf Node 23 aus $irgendwelchen Gründen die
Service-Config mit beeinflusst dann weißt Du auch warum. Und wirst
idealerweise anfangen, Dich intensiv mit "provisioning" auseinander zu
setzen ...

--
SIC SEMPER
+--|=======>
TYRANNIS

[Ulli Horlacher]

Das aendert die Umgebung von allen (neuen) Prozessen.
Deshalb kopier ich das nach /var/tmp/sw/
Da stoerts nicht.

[Marcel Mueller]

Am 25.09.22 um 11:39 schrieb Dietz Proepper:

> Marcel Mueller <news.5...@spamgourmet.org> wrote:
>
>> Am 25.09.22 um 11:09 schrieb Marc Haber:
>>> Shellaliase haben bei Leuten aus den Operations den Nachteil, dass
>>> sie dort, wo man sie braucht, nie installiert sind.
>>
>> Das kann eine kleine Batch lösen, die in einem im persönlichen
>> Userprofile referenzierten Path liegt, oder aber auf allen
>> betroffenen Kisten einmal nach /usr/local/bin kopiert wird.
>
> Das führt dann dazu, dass $jede Box ein klein wenig anders aussieht.
>
> DAS WILLST DU NICHT. GLAUBE MIR! (Zumindest bei mehr als drei
> Maschinen.)

Mit einem halben Dutzend klappt es ganz gut.

> Spätestens wenn Du mal 4h debuggt hast, warum sich Node 23 im Cluster
> anders verhält als die anderen 42 Maschinen und dann feststellst, dass
> die Individualconfig auf Node 23 aus $irgendwelchen Gründen die
> Service-Config mit beeinflusst dann weißt Du auch warum.

In einem Cluster macht man das entweder mit einem Mount oder einer
Replikation von einem Master Node.


Marcel

[Marc Haber]

Marcel Mueller <news.5...@spamgourmet.org> wrote:
>In einem Cluster macht man das entweder mit einem Mount oder einer
>Replikation von einem Master Node.

der modernere Ansatz heißt Konfigurationsmanagement. Oder Container.