Jason King <[email protected]> wrote: > On Tue, Jan 20, 2009 at 9:03 AM, Dave Miner <[email protected]> wrote:
> > Because I'm an optimist? There's trying and failing, and then there's > > failing to try. My experiences are that after you negotiated things with the maintainer, RMS chimes in and prevents things from happening. > > I won't speculate on why the Linux distributors have made the choices > > they have since I'm uninformed there, but the case of ACL's which are > > standardized in NFSv4 would seem to be less a matter of OS-specific > > features than lacking support for standards. POSIX draft ACLs are still more common than NTFS ACLs. As you may see with star, it is even possible to have them in tar archives in a OS independent way. In order to support NTFS ACLs, star may need to include code to parse and convert the ACL text entries. > What about extended attributes? Are those standardized enough that > the implementation on Solaris would not be considered Solaris > specific? Their support also an issue for chmod and ls. At which level do you like to discuss this? There are ongoing ports for NFSv4 for e.g. Linux and FreeBSD that port not only the POSIX.1-2008 funtionality of the *at() system interfaces (that only allow these functions to be used for accessing paths with infinite lenght and to simulate a thread specific chdir()) but also the extension from Sun that implement support for extended attribute files. The main problem is that different camps use different/same wordings for partially similar interfaces and that there does not seem to be a common understanding on how to use the interfaces in a OS independent way. IIRC, Sun introduced the current idea of extended attribute files in Autumn 2000 after Microsoft tried to standardize the MS interface "filename:stream" and later something that was based on a special "..." directory in the POSIX committee. MS failed in this POSIX discussion because the MS proposal could not be made POSIX compliant. Sun failed however to present a definition on how to use the new extended sttribute file interface in order to implement extended attributes as found on Linux and FreeBSD and on how to use it to support Mac extensions. Note that from the viewpoint of a Linux or FreeBSD extended attributes implemenation, the Solaris extended attribute files are only an implementation detail that currently lacks a mapping. If you like to discuss how extended attribute files should be archived inside a tar archive, then I hereby invite anybody who is intersted to do this on the star development mailing lists. The method currently used by Sun tar is unusable because it is based on POSIX.1-1988 tar extensions that have already been deprecated at the time Sun offered Sun tar extensions based on the POSIX.1-1988 tar archive format. If we like to have an accepted and portable implementation, we need a definition for extensions that are based on POSIX.1-2001 tar extensions. Jörg -- EMail:[email protected] (home) Jörg Schilling D-13353 Berlin [email protected] (uni) [email protected] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily _______________________________________________ indiana-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
