[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: [ANN] LuaFileSystem 1.2.1 Released (Andre Carregal)
- From: Tomas Guisasola Gorham <tomas@...>
- Date: Sat, 19 May 2007 11:29:53 -0300 (BRT)
Hi duck (and others)
> I would be most grateful if the standard distro could be updated (I'd
> call it fixed, as you can consider this a bug IMO :-) so that the mode
> field returned by lfs.attributes() is a table of strings, not just a
> single string. (For backward compatibility, perhaps another field could
> be added to the table for this additional data.)
>
> It's not possible (that I can see) with lfs to enumerate all links in
> a file system -- because any symlink to a directory is always identified
> as "directory", and never as "link". (The mode2string function returns
> as soon as it sees S_ISDIR() is true, and this is tested before S_ISLNK().
I checked the definitions of those macros:
/usr/include/linux/stat.h:#define S_ISREG(m) (((m) & S_IFMT) == S_IFREG)
/usr/include/linux/stat.h:#define S_ISDIR(m) (((m) & S_IFMT) == S_IFDIR)
/usr/include/linux/stat.h:#define S_ISLNK(m) (((m) & S_IFMT) == S_IFLNK)
So, despite our implementation (which return as soon as it sees
a true flag) using these macros will not solve the problem. Also, we
have to change `stat' (which follows the links instead of informing them)
to `lstat' (which provides informations about the links)
( For reference, the man page says:
The following flags are defined for the st_mode field:
S_IFMT 0170000 bitmask for the file type bitfields
S_IFSOCK 0140000 socket
S_IFLNK 0120000 symbolic link
S_IFREG 0100000 regular file
S_IFBLK 0060000 block device
S_IFDIR 0040000 directory
S_IFCHR 0020000 character device
S_IFIFO 0010000 FIFO
)
I think we could use macros as those above, but changing the
`==' by `&'. Don't you agree?
Anyway, I propose that `lfs.attributes(path).modes' (note the
new name `modes' instead of `mode') should return a table as a set:
{
link = true,
file = true,
}
What do you think?
Tomás