File systems' timestamps apparently formatted in a wrong way ...
~
... or ls not properly displaying them in some cases. ~ I got this compressed file that seems to be the metadata snapshot of a file system you get by running: ~ ls -lR ~ but not all timestamps are formatted the same. You get them as, say, "Mar 24 2004", but also as "Dec 26 09:55" (without the year!) and they are (or seem to be) files in the same directory ~ Why would that be? ~ Thanks lbrtchx -- To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org Archive: AANLkTinS-QFS4h+LazyfnJMNB9FxrgAqcTympkVZ0Obu@mail.gmail.com ">http://lists.debian.org/AANLkTinS-QFS4h+LazyfnJMNB9FxrgAqcTympkVZ0Obu@mail.gmail.com |
File systems' timestamps apparently formatted in a wrong way ...
Albretch Mueller <lbrtchx@gmail.com> wrote:
>~ > ... or ls not properly displaying them in some cases. >~ ^ I don’t even want to know what these are doing here… > but not all timestamps are formatted the same. You get them as, say, >"Mar 24 2004", but also as "Dec 26 09:55" (without the year!) and they >are (or seem to be) files in the same directory The latter is simply a way to get more information in there – if there’s no year, it either means the current year (i. e. 2011) or the last 365 days (i. e. January 3rd, 2010 – now). I don’t know which of these, although I’d guess it is the former again to avoid ambiguities when dealing with broken file systems. Best regards, Claudius -- Put your trust in those who are worthy. http://chubig.net/ -- To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org Archive: ifpstp$u39$1@dough.gmane.org">http://lists.debian.org/ifpstp$u39$1@dough.gmane.org |
File systems' timestamps apparently formatted in a wrong way ...
On Sun, 02 Jan 2011 12:41:38 +0000, Albretch Mueller wrote:
> ~ > ... or ls not properly displaying them in some cases. > ~ > I got this compressed file that seems to be the metadata snapshot of > a file system you get by running: > ~ > ls -lR > ~ > but not all timestamps are formatted the same. You get them as, say, > "Mar 24 2004", but also as "Dec 26 09:55" (without the year!) and they > are (or seem to be) files in the same directory ~ > Why would that be? I get the same: sm01@stt008:~/Documentos/dsc-fotos/2010/sony$ ls -lR | tail -rwxr--r-- 1 sm01 sm01 533809 ago 21 18:12 DSC02335.JPG -rwxr--r-- 1 sm01 sm01 484485 ago 21 18:12 DSC02336.JPG -rwxr--r-- 1 sm01 sm01 517789 ago 21 18:14 DSC02338.JPG -rwxr--r-- 1 sm01 sm01 495196 ago 21 18:15 DSC02339.JPG -rwxr--r-- 1 sm01 sm01 541253 ago 28 13:00 DSC02340.JPG -rwxr--r-- 1 sm01 sm01 538118 ago 28 13:00 DSC02341.JPG -rwxr--r-- 1 sm01 sm01 558677 ago 28 13:01 DSC02342.JPG -rwxr--r-- 1 sm01 sm01 546987 ago 28 13:01 DSC02343.JPG -rwxr--r-- 1 sm01 sm01 543089 ago 28 13:01 DSC02344.JPG -rwxr--r-- 1 sm01 sm01 527500 sep 12 21:00 DSC02347.JPG If you need accuracy, better use "--full-time" parameter. sm01@stt008:~/Documentos/dsc-fotos/2010/sony$ ls -l --full-time |tail -rwxr--r-- 1 sm01 sm01 533809 2010-08-21 18:12:16.000000000 +0200 DSC02335.JPG -rwxr--r-- 1 sm01 sm01 484485 2010-08-21 18:12:36.000000000 +0200 DSC02336.JPG -rwxr--r-- 1 sm01 sm01 517789 2010-08-21 18:14:54.000000000 +0200 DSC02338.JPG -rwxr--r-- 1 sm01 sm01 495196 2010-08-21 18:15:08.000000000 +0200 DSC02339.JPG -rwxr--r-- 1 sm01 sm01 541253 2010-08-28 13:00:38.000000000 +0200 DSC02340.JPG -rwxr--r-- 1 sm01 sm01 538118 2010-08-28 13:00:52.000000000 +0200 DSC02341.JPG -rwxr--r-- 1 sm01 sm01 558677 2010-08-28 13:01:14.000000000 +0200 DSC02342.JPG -rwxr--r-- 1 sm01 sm01 546987 2010-08-28 13:01:28.000000000 +0200 DSC02343.JPG -rwxr--r-- 1 sm01 sm01 543089 2010-08-28 13:01:52.000000000 +0200 DSC02344.JPG -rwxr--r-- 1 sm01 sm01 527500 2010-09-12 21:00:20.000000000 +0200 DSC02347.JPG Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org Archive: pan.2011.01.02.13.00.51@gmail.com">http://lists.debian.org/pan.2011.01.02.13.00.51@gmail.com |
File systems' timestamps apparently formatted in a wrong way ...
Albretch Mueller wrote:
> ~ > ... or ls not properly displaying them in some cases. > ~ > I got this compressed file that seems to be the metadata snapshot of > a file system you get by running: > ~ > ls -lR > ~ > but not all timestamps are formatted the same. You get them as, say, > "Mar 24 2004", but also as "Dec 26 09:55" (without the year!) and they > are (or seem to be) files in the same directory > ~ > Why would that be? Under the C or POSIX locale, timestamps which are near to now are shown with the time and without the year; those well removed show the year, but not the time. I'm not sure of exactly how far into the future or past the cutoff point is. This is generally useful to human readers but a pain for automated parsing. With GNU ls, you can pass --full-time or --time-style=<various options> (see the ls man page for details); alternatively stat can be useful. Other locales may vary. -- Chris Jackson Shadowcat Systems Ltd. -- To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org Archive: 4D20774D.4000401@shadowcat.co.uk">http://lists.debian.org/4D20774D.4000401@shadowcat.co.uk |
File systems' timestamps apparently formatted in a wrong way ...
Albretch Mueller wrote:
> but not all timestamps are formatted the same. You get them as, say, > "Mar 24 2004", but also as "Dec 26 09:55" (without the year!) and they > are (or seem to be) files in the same directory > ~ > Why would that be? Because the original Unix ls command many years ago did this to compress the information give to you. If it is a recent file then you get the time down to the minute and the year is assumed to be the most recent year. But if the file is much older then you don't really care about the minute but you do care about the year. You are a human, this is the way humans talk. That is how the ls command has always been on Unix systems. If you don't like it then you can supply a ls option --time-style=STYLE or TIME_STYLE variable and change the format to your liking. But there is no need to guess at this. It is all documented. Start at the top node of the documentation. $ info coreutils 'ls invocation' Press the spacebar to page through the documentation until you get to the section "10.1.6 Formatting file timestamps" where all is documented. By default, file timestamps are listed in abbreviated form. Most locales use a timestamp like `2002-03-30 23:45'. However, the default POSIX locale uses a date like `Mar 30 2002' for non-recent timestamps, and a date-without-year and time like `Mar 30 23:45' for recent timestamps. A timestamp is considered to be "recent" if it is less than six months old, and is not dated in the future. And the documentation goes on to the formatting controls that affect the time format. Good stuff. Bob |
File systems' timestamps apparently formatted in a wrong way ...
Chris Jackson <c.jackson@shadowcat.co.uk> writes:
> Albretch Mueller wrote: > >> ~ >> ... or ls not properly displaying them in some cases. >> ~ >> I got this compressed file that seems to be the metadata snapshot of >> a file system you get by running: >> ~ >> ls -lR >> ~ >> but not all timestamps are formatted the same. You get them as, say, >> "Mar 24 2004", but also as "Dec 26 09:55" (without the year!) and they >> are (or seem to be) files in the same directory >> ~ >> Why would that be? > > > Under the C or POSIX locale, timestamps which are near to now are shown > with the time and without the year; those well removed show the year, > but not the time. I'm not sure of exactly how far into the future or > past the cutoff point is. This is generally useful to human readers but > a pain for automated parsing. With GNU ls, you can pass --full-time or > --time-style=<various options> (see the ls man page for details); > alternatively stat can be useful. Other locales may vary. You can also use the same options in the environment variable TIME_STYLE. -- Carl Johnson carlj@peak.org -- To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org Archive: 87aajjdwe9.fsf@oak.localnet">http://lists.debian.org/87aajjdwe9.fsf@oak.localnet |
File systems' timestamps apparently formatted in a wrong way ...
In <AANLkTinS-QFS4h+LazyfnJMNB9FxrgAqcTympkVZ0Obu@mail.gmail.com >, Albretch
Mueller wrote: > ls -lR > > but not all timestamps are formatted the same. You get them as, say, >"Mar 24 2004", but also as "Dec 26 09:55" (without the year!) and they >are (or seem to be) files in the same directory > > Why would that be? From the Single Unix Specification version 2: "If the -l option is specified, the following information will be written: "%s %u %s %s %u %s %s ", <file mode>, <number of links>, <owner name>, <group name>, <number of bytes in the file>, <date and time>, <pathname>" "The <date and time>, field will contain the appropriate date and timestamp of when the file was last modified. In the POSIX locale, the field is the equivalent of the output of the following date command: date "+%b %e %H:%M" if the file has been modified in the last six months, or: date "+%b %e %Y" (where two space characters are used between %e and %Y) if the file has not been modified in the last six months or if the modification date is in the future, except that, in both cases, the final newline character produced by date is not included and the output is as if the date command were executed at the time of the last modification date of the file rather than the current time. When the LC_TIME locale category is not set to the POSIX locale, a different format and order of presentation of this field may be used." -- Boyd Stephen Smith Jr. ,= ,-_-. =. bss@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/ \_/ |
| All times are GMT. The time now is 10:22 PM. |
VBulletin, Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.