Hello,
I was wondering, are there any plans to support extended attributes
(e.g. as in the Linux ext3 file system) in NSPR? I believe that not
all file systems support this feature and if they do - the
implementation differs(e.g. - ext3, FAT, HPFS). Because of this, it
seems that it would be useful to have a platform-independent API for
accessing extended attributes.
Peter
dev-tech-nspr mailing list
dev-tech-nspr (AT) lists (DOT) mozilla.org

Peter Djalaliev wrote:
Hello,

I was wondering, are there any plans to support extended attributes
(e.g. as in the Linux ext3 file system) in NSPR? I believe that not
all file systems support this feature and if they do - the
implementation differs(e.g. - ext3, FAT, HPFS). Because of this, it
seems that it would be useful to have a platform-independent API for
accessing extended attributes.

Hi Peter,

There are no plans to support extended attributes.
I don't even know what they are. Could you explain?
The only thing I can find from a quick web search is
that extended attributes are metadata for files:

Right now NSPR returns the following file info:
#17013

struct PRFileInfo64 {
PRFileType type;
PRUint64 size;
PRTime creationTime;
PRTime modifyTime;
};

I guess we can add at least "last access time", which
is widely supported now.

Here is the current standard Unix stat structure:

Windows BY_HANDLE_FILE_INFRMATIN structure:

Windows WIN32_FIND_DATA structure:

I hope I didn't misunderstand your question.

Wan-Teh

dev-tech-nspr mailing list
dev-tech-nspr (AT) lists (DOT) mozilla.org

Wan-teh,

I am sorry I couldn't reply to this earlier, I have just been
overwhelmed with things.

Here is a link:

Extended attributes augment the standard set of attributes stored with
a file or directory (size, date creates, last date accessed, etc.).
They are just customly-chosen name/value pairs that can be used to
store metadata with a file or a directory. Different filesystems
implement them differently, but as far as I know, they are implemented
in the ext2, ext3, ReiserFS, JFS, XFS and NFS filesystems in Linux
kernels 2.6. The HPFS filesystem provided with S/2 supports them,
too.

In Linux, one way that extended attributes have been used is to
implement PSIX-like access control lists. (link:
http://acl.bestbits.at/)

The utilities used to manage extended attributes under Linux are
getxattr, setxattr, listxattr, removexattr. Their man pages include
some additional description of extanded attributes.

Peter

dev-tech-nspr mailing list
dev-tech-nspr (AT) lists (DOT) mozilla.org

Peter Djalaliev wrote:

Here is a link:

Extended attributes augment the standard set of attributes stored with
a file or directory (size, date creates, last date accessed, etc.).
They are just customly-chosen name/value pairs that can be used to
store metadata with a file or a directory. Different filesystems
implement them differently, but as far as I know, they are implemented
in the ext2, ext3, ReiserFS, JFS, XFS and NFS filesystems in Linux
kernels 2.6. The HPFS filesystem provided with S/2 supports them,
too.

I'm afraid that adding extended file attributes support to
NSPR at this stage would be a "portable way to write non-portable
code" because the names in the name-value pairs seem system
dependent. The wikipedia article you cited says the names
must be prefixed with a namespace on Linux. Have you thought
about how to deal with the required namespace? For example,
would NSPR automatically prepend the "user." prefix to a name?

Wan-Teh

dev-tech-nspr mailing list
dev-tech-nspr (AT) lists (DOT) mozilla.org

Hmsorry, can you explain about what exactly you meant about
"portable way for writing non-portable code"?

Yeah, under Linux the names of the extended attributes must belong to
namespaces: currently the ones defined are "security", "system",
"trusted", and "user". "Security" is reserved for kernel security
modules while "system" is used for system objects like ACLs and
capabilities, but both seem to be reserved for kernel usage. "Trusted"
attributes are visible and accessible by processes with the
CAP_SYS_ADMIN capability (e.g. processes running with root privileges).
So, it seems that the only namespace, which ordinary NSPR-based
user-land applications can use freely, is "user". In that case, we can
have NSPR preprend "user." to extended attribute names.

This information comes from:

Another issue for portability could be the sizes of the extended
attributes. The ext2 and ext3 filesystems, I believe, restrict
extended attribute values to the size of a single filesystem block. As
the link above says, this size is specified when the filesystem is
created and can be 1024, 2048 or 4096 bytes. I think the default is
4096 bytes.

Peter

dev-tech-nspr mailing list
dev-tech-nspr (AT) lists (DOT) mozilla.org

A problem with portability will probably be the fact that extended
attributes have not been implemented for many file systems. Their
implementation in ext2, ext3, XFS, ReiserFS will make them available
for Linux platforms, MS and some Unix kernels (shaky support for the
last two). The HPFS implementation of EAs would make them available
for S/2 platforms. However, support for extended attributes in other
filesystems/platforms seems to be lacking.

Are features implemented in NSPR usually present on all platforms
supported by NSPR?

Peter

dev-tech-nspr mailing list
dev-tech-nspr (AT) lists (DOT) mozilla.org