date:20140421

xattr and acl support in ls

2014-04-21 Thread April Arcus

Feature request per @pixelbeat_ ( 
https://twitter.com/pixelbeat_/status/458221138964127745 )

Apple's fork of FreeBSD's ls supports the options -@ and -e to show extended 
attributes and access control lists, respectively:

Zephyr:~ ril$ /bin/ls -lFh -e ~
total 2944
drwxr-xr-x4 ril  staff   136B Feb 17 16:06 Applications/
drwxr-xr-x@   5 ril  staff   170B Mar 31 20:39 Applications (Parallels)/
drwxr-xr-x  156 ril  staff   5.2K Nov  9  2011 CS3 Fonts/
drwxr-xr-x@  16 ril  staff   544B Dec 11 23:35 Classic/
drwx--@  63 ril  staff   2.1K Apr 19 14:35 Desktop/
 0: group:everyone deny delete
drwx--+  30 ril  staff   1.0K Feb 17 15:47 Documents/
 0: group:everyone deny delete
drwx--+ 179 ril  staff   5.9K Apr 21 10:52 Downloads/
 0: group:everyone deny delete

Zephyr:~ ril$ /bin/ls -lFh -@ ~
total 2944
drwxr-xr-x4 ril  staff   136B Feb 17 16:06 Applications/
drwxr-xr-x@   5 ril  staff   170B Mar 31 20:39 Applications (Parallels)/
com.apple.FinderInfo  32B
drwxr-xr-x  156 ril  staff   5.2K Nov  9  2011 CS3 Fonts/
drwxr-xr-x@  16 ril  staff   544B Dec 11 23:35 Classic/
com.apple.FinderInfo  32B
org.BasiliskII.ExtendedFinderInfo 16B
org.BasiliskII.FinderInfo 16B
drwx--@  63 ril  staff   2.1K Apr 19 14:35 Desktop/
CDQJEIS1UO5TGNv0Q2Y_dvi9Ui8Oe2bc=235B
drwx--+  30 ril  staff   1.0K Feb 17 15:47 Documents/
drwx--+ 179 ril  staff   5.9K Apr 21 10:52 Downloads/

coreutils ls can detect the presence of an ACL, but cannot display it, and is 
oblivious to xattrs:

Zephyr:~ ril$ /usr/local/Cellar/coreutils/8.22/bin/gls -lFh ~
total 1.5M
drwxr-xr-x4 ril staff  136 Feb 17 16:06 Applications/
drwxr-xr-x5 ril staff  170 Mar 31 20:39 Applications (Parallels)/
drwxr-xr-x  156 ril staff 5.2K Nov  9  2011 CS3 Fonts/
drwxr-xr-x   16 ril staff  544 Dec 11 23:35 Classic/
drwx--+  63 ril staff 2.1K Apr 19 14:35 Desktop/
drwx--+  30 ril staff 1020 Feb 17 15:47 Documents/
drwx--+ 179 ril staff 6.0K Apr 21 10:52 Downloads/

I am currently using a kludgy shim to dynamically switch between BSD and GNU ls 
depending on the passed in flags ( https://gist.github.com/AprilArcus/11124713 
) - it would be great if coreutils supported these features, so that I could 
stop doing this ^^

-April

stat: clarify mtime vs ctime [patch]

2014-04-21 Thread Assaf Gordon


Hello,

Would you be receptive to adding a tiny patch to 'stat' to clarify the 
difference between modification time and change time?

Currently, it simply says:
  %y   time of last modification, human-readable
  %Y   time of last modification, seconds since Epoch
  %z   time of last change, human-readable
  %Z   time of last change, seconds since Epoch

And for most non-unix experts, last modification is (almost) a synonym for last 
change (IMHO).

The patch changes:
  modification - data modification
  change - status change
And adds one clarification paragraph to the docs.

While this will not immediately resolve all questions, it will at least hint users which option 
they need (as data is different from status).

The words data and status are also used (for mtime and ctime, respectively) 
in the POSIX pages of 'sys/stat.h':
http://pubs.opengroup.org/onlinepubs/009695399/basedefs/sys/stat.h.html


Perhaps, in addition, add a new FAQ ?
Something like:

Q. What is the difference between access time, data modification time and 
status change time ?
A. Most UNIX systems keeps track of different times for each file.
Access Time keeps track of the last time a file was opened for reading.
Data Modification time keeps tracks of the last time file's content has been 
modified.
Status Change time keeps tracks of the last time a file's status (e.g. mode, 
owner, group, hard-links) was modified.

Configuration varies between filesystems - not all systems keep track of all 
three times.

To show Access time, use ls -lu or stat's %X and %x formats.
To show Data modification time, use ls -l or stat's %Y and %y formats.
To show Status change time, use ls -lc or stat's %Z and %z formats.

Example:
# Create a new file
$ echo hello  test.txt

# Show the file's time stamps
$ stat --printf Access: %x\nModify: %y\nChange: %z\n test.txt
Access: 2014-04-21 14:01:00.131648000 +
Modify: 2014-04-21 14:01:00.131648000 +
Change: 2014-04-21 14:01:00.131648000 +

# Wait 5 seconds, then update the file's content.
# NOTE: Status change time is also updated.
$ sleep 5 ; echo world  test.txt
$ stat --printf Access: %x\nModify: %y\nChange: %z\n test.txt
Access: 2014-04-21 14:01:00.131648000 +
Modify: 2014-04-21 14:01:05.161657000 +
Change: 2014-04-21 14:01:05.161657000 +

# Wait 5 seconds, then update the file's status (but not content)
$ sleep 5 ; chmod o-rwx test.txt
$ stat --printf Access: %x\nModify: %y\nChange: %z\n test.txt
Access: 2014-04-21 14:01:00.131648000 +
Modify: 2014-04-21 14:01:05.161657000 +
Change: 2014-04-21 14:01:10.250232749 +

# Wait 5 seconds, then read (access) the file's content
$ sleep 5 ; wc test.txt  /dev/null
$ stat --printf Access: %x\nModify: %y\nChange: %z\n test.txt
Access: 2014-04-21 14:01:15.298241904 +
Modify: 2014-04-21 14:01:05.161657000 +
Change: 2014-04-21 14:01:10.250232749 +

# Show Data Modification time with 'ls -l'
$  ls --full-time -log test.txt
-rw-r- 1 12 2014-04-21 14:01:05.161657000 + test.txt

# Show Status Change time with 'ls -c'
$ ls --full-time -log -c test.txt
-rw-r- 1 12 2014-04-21 14:01:10.250232749 + test.txt

# Show Last Access time with 'ls -u'
$ ls --full-time -log -u test.txt
-rw-r- 1 12 2014-04-21 14:01:15.298241904 + test.txt



Regards,
 -gordon

From 4cf4784aafdf45fd3dec3855b9320d72dcd1a6ec Mon Sep 17 00:00:00 2001
From: Assaf Gordon assafgor...@gmail.com
Date: Mon, 21 Apr 2014 14:31:23 -0400
Subject: [PATCH] stat: clarify mtime vs ctime in usage(), doc

Change modification time to data modification time,
change time to status change time.

* src/stat.c: improve usage()
* doc/coreutils.texi: add clarification paragraph
---
 doc/coreutils.texi | 19 +++
 src/stat.c |  8 
 2 files changed, 19 insertions(+), 8 deletions(-)

diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 6c49385..e979c88 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -11829,10 +11829,10 @@ The valid @var{format} directives for files with @option{--format} and
 @item %W - Time of file birth as seconds since Epoch, or @samp{0}
 @item %x - Time of last access
 @item %X - Time of last access as seconds since Epoch
-@item %y - Time of last modification
-@item %Y - Time of last modification as seconds since Epoch
-@item %z - Time of last change
-@item %Z - Time of last change as seconds since Epoch
+@item %y - Time of last data modification
+@item %Y - Time of last data modification as seconds since Epoch
+@item %z - Time of last status change
+@item %Z - Time of last status change as seconds since Epoch
 @end itemize
 
 The @samp{%t} and @samp{%T} formats operate on the st_rdev member of
@@ -11864,6 +11864,17 @@ precision:
   [1288929712.114951834]
 @end example
 
+@emph{Access time} formats (@samp{%x},@samp{%X}) output the last time the
+file

Re: stat: clarify mtime vs ctime [patch]

2014-04-21 Thread Pádraig Brady

On 04/21/2014 08:14 PM, Assaf Gordon wrote:
 Hello,
 
 Would you be receptive to adding a tiny patch to 'stat' to clarify the 
 difference between modification time and change time?
 
 Currently, it simply says:
   %y   time of last modification, human-readable
   %Y   time of last modification, seconds since Epoch
   %z   time of last change, human-readable
   %Z   time of last change, seconds since Epoch
 
 And for most non-unix experts, last modification is (almost) a synonym for 
 last change (IMHO).
 
 The patch changes:
   modification - data modification
   change - status change
 And adds one clarification paragraph to the docs.

This clarification is worth making, thanks!

 While this will not immediately resolve all questions, it will at least hint 
 users which option they need (as data is different from status).
 
 The words data and status are also used (for mtime and ctime, 
 respectively) in the POSIX pages of 'sys/stat.h':
 http://pubs.opengroup.org/onlinepubs/009695399/basedefs/sys/stat.h.html

I might have gone with attributes rather than status,
but given the above references, status is fine I think.

 Perhaps, in addition, add a new FAQ ?

Let's avoid the FAQ for the moment.
Hopefully the improved docs will avoid the need.

From 4cf4784aafdf45fd3dec3855b9320d72dcd1a6ec Mon Sep 17 00:00:00 2001
 From: Assaf Gordon assafgor...@gmail.com
 Date: Mon, 21 Apr 2014 14:31:23 -0400
 Subject: [PATCH] stat: clarify mtime vs ctime in usage(), doc

s/stat:/doc:/

 +@emph{Access time} formats (@samp{%x},@samp{%X}) output the last time the
 +file was accessed for reading (if supported by the filesystem). Access time 
 is
 +also shown with @command{ls -lu}.
 +@emph{Data modification} format (@samp{%y}, @samp{%Y})
 +outputs the time the file's content was modified (e.g. by a program writing
 +to the file). Data modification time is also shown with @command{ls -l}.
 +@emph{Status change} format (@samp{%z},@samp{%Z}) outputs the
 +time the file's status was modified (e.g. owner, group, mode changes). Status
 +change time is also shown with @command{ls -lc}.

s/filesystem/file system/ for consistency, but
if the file was just opened for reading, then access time isn't updated,
only if data is read. Also for performance reasons, modern Linux systems
only update atime if it's older than [cm]time.
I.E. with relatime enabled, it's really only an indicator
as to whether the file has been read since it was last updated.
So I think this whole block might add more ambiguity than
any additional clarification. OK to drop this block?

 diff --git a/src/stat.c b/src/stat.c
 index fffebe3..7d43eb5 100644
 --- a/src/stat.c
 +++ b/src/stat.c
 @@ -1457,10 +1457,10 @@ The valid format sequences for files (without 
 --file-system):\n\
%W   time of file birth, seconds since Epoch; 0 if unknown\n\
%x   time of last access, human-readable\n\
%X   time of last access, seconds since Epoch\n\
 -  %y   time of last modification, human-readable\n\
 -  %Y   time of last modification, seconds since Epoch\n\
 -  %z   time of last change, human-readable\n\
 -  %Z   time of last change, seconds since Epoch\n\
 +  %y   time of last data modification, human-readable\n\
 +  %Y   time of last data modification, seconds since Epoch\n\
 +  %z   time of last status change, human-readable\n\
 +  %Z   time of last status change, seconds since Epoch\n\

+1 to this part.

thanks,
Pádraig.

Re: xattr and acl support in ls

2014-04-21 Thread Pádraig Brady

Thanks for the details.
I can see the usefulness of displaying all meta data together.
I presume one can specify -e and -@ together also?
More notes below...

On 04/21/2014 07:49 PM, April Arcus wrote:
 Feature request per @pixelbeat_ ( 
 https://twitter.com/pixelbeat_/status/458221138964127745 )
 
 Apple's fork of FreeBSD's ls supports the options -@ and -e to show extended 
 attributes and access control lists, respectively:
 
 Zephyr:~ ril$ /bin/ls -lFh -e ~
 total 2944
 drwxr-xr-x4 ril  staff   136B Feb 17 16:06 Applications/
 drwxr-xr-x@   5 ril  staff   170B Mar 31 20:39 Applications (Parallels)/
 drwxr-xr-x  156 ril  staff   5.2K Nov  9  2011 CS3 Fonts/
 drwxr-xr-x@  16 ril  staff   544B Dec 11 23:35 Classic/
 drwx--@  63 ril  staff   2.1K Apr 19 14:35 Desktop/
  0: group:everyone deny delete
 drwx--+  30 ril  staff   1.0K Feb 17 15:47 Documents/
  0: group:everyone deny delete
 drwx--+ 179 ril  staff   5.9K Apr 21 10:52 Downloads/
  0: group:everyone deny delete

So the extended attributes indicator '@' will override the ACLs indicator '+'.
That's a general awkwardness about trying to indicate many things
with a single character. In this case the ambiguity is resolved
by also listing the ACLs.

For reference GNU considers access meta data for this character,
with . implying just a security context, and + indicating anything else
(i.e. and/or ACLs).

 Zephyr:~ ril$ /bin/ls -lFh -@ ~
 total 2944
 drwxr-xr-x4 ril  staff   136B Feb 17 16:06 Applications/
 drwxr-xr-x@   5 ril  staff   170B Mar 31 20:39 Applications (Parallels)/
   com.apple.FinderInfo  32B
 drwxr-xr-x  156 ril  staff   5.2K Nov  9  2011 CS3 Fonts/
 drwxr-xr-x@  16 ril  staff   544B Dec 11 23:35 Classic/
   com.apple.FinderInfo  32B
   org.BasiliskII.ExtendedFinderInfo 16B
   org.BasiliskII.FinderInfo 16B
 drwx--@  63 ril  staff   2.1K Apr 19 14:35 Desktop/
   CDQJEIS1UO5TGNv0Q2Y_dvi9Ui8Oe2bc=235B

Interesting. In this case you wouldn't know that Desktop/ had ACLs,
so personally I would have changed the '@' to '+' in this case
as displaying the xattrs would resolve that ambiguity.

 drwx--+  30 ril  staff   1.0K Feb 17 15:47 Documents/
 drwx--+ 179 ril  staff   5.9K Apr 21 10:52 Downloads/

 coreutils ls can detect the presence of an ACL, but cannot display it, and is 
 oblivious to xattrs:
 
 Zephyr:~ ril$ /usr/local/Cellar/coreutils/8.22/bin/gls -lFh ~
 total 1.5M
 drwxr-xr-x4 ril staff  136 Feb 17 16:06 Applications/
 drwxr-xr-x5 ril staff  170 Mar 31 20:39 Applications (Parallels)/
 drwxr-xr-x  156 ril staff 5.2K Nov  9  2011 CS3 Fonts/
 drwxr-xr-x   16 ril staff  544 Dec 11 23:35 Classic/
 drwx--+  63 ril staff 2.1K Apr 19 14:35 Desktop/
 drwx--+  30 ril staff 1020 Feb 17 15:47 Documents/
 drwx--+ 179 ril staff 6.0K Apr 21 10:52 Downloads/
 
 I am currently using a kludgy shim to dynamically switch between BSD and GNU 
 ls depending on the passed in flags ( 
 https://gist.github.com/AprilArcus/11124713 ) - it would be great if 
 coreutils supported these features, so that I could stop doing this ^^

So something that might be useful as a first step to both ls(1) and stat(1)
would be to at least indicate the presence of extended attributes.
Note often security contexts and ACLs are implemented using extended attributes,
to that would further complicate things. I don't know the implementation
details of ACLs on HFS+ for example, and whether they're separate.

thanks,
Pádraig.

xattr and acl support in ls

stat: clarify mtime vs ctime [patch]

Re: stat: clarify mtime vs ctime [patch]

Re: xattr and acl support in ls

4 matches

Site Navigation

Mail list logo

Footer information