On 7-2-2011 1:41, Reinhard Kotucha wrote:
No, it's not a bug. The name "attributes" is misleading, "stat" would be better. It *has* a defined meaning, it just returns what's stored in the stat structure of a particular file:
struct stat { dev_t st_dev; /* ID of device containing file */ ino_t st_ino; /* inode number */ mode_t st_mode; /* protection */ nlink_t st_nlink; /* number of hard links */ uid_t st_uid; /* user ID of owner */ gid_t st_gid; /* group ID of owner */ dev_t st_rdev; /* device ID (if special file) */ off_t st_size; /* total size, in bytes */ blksize_t st_blksize; /* blocksize for file system I/O */ blkcnt_t st_blocks; /* number of 512B blocks allocated */ time_t st_atime; /* time of last access */ time_t st_mtime; /* time of last modification */ time_t st_ctime; /* time of last status change */ };
This is exactly the information you see in directory listings.
lfs.attributes supports the stat() system call directly, except that st_blksize and st_blocks are not defined on Windows and that st_mode is split up into "permissions" and "mode".
So where does the 'permissions' info in lfs.attributes come from then? I assume that that should reflect access. Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------