[EMAIL PROTECTED] wrote:
> >Does anyone know when the new POSIX-draft versions of |mkdirat()|&co.
> >(e.g |mkdirat()|, |faccessat()|, |fchmodat()|, |fchownat()|,
> >|fstatat()|, |linkat()|, |mknodat()|, |openat()|, |symlinkat()|,
> >|unlinkat()|, |utimensat()|) will be available in Solaris (AFAIK these
> >functions were added to the Linux kernel with release "2.6.16" (per
> >http://www.die.net/doc/linux/man/man2/mkdirat.2.html)) ?
> >We're currently working in threading support for an application and will
> >need such functions to make sure any operation of one thread doesn't
> >affect others (the only workaround is to turn eveything into absolute
> >paths which will become tricky in other situations...).
>
> Not until it's clear there is a consensus about the functiosn.
>
> Some of these had already been added in Solaris 2.6, I think,
> where they originate.
>
> For now we have:
>
> fchownat
> fstatat
> futimesat
> unlinkat
> openat
> __accessat (which was added waiting for the final
> POSIX standard)
Why the "__"-underscores ?
> renameat
>
> These functions are relatively straightforward to implement in the
> kernel
Are you going to switch over the old calls (e.g. |open()| etc.) over to
the new functions and use cwd as |fd| argument ?
> and it is probably best to implement what is missing as private
> functions untile the standard has gravitated toward consensus.
>
> There's some discussion about the 'f' argument.
Do you mean the |flags| field ?
> Note, though, that much of the *at functions can be implemented as
> follows:
>
> int
> fchownat(int fd, const char *path, uid_t owner, gid_t group, int flag)
Why is |flags| a |signed int| and not an |unsigned int| ?
> {
> char *buf;
> size_t len = snprintf(buf, 0, "/proc/self/fd/%d/%s", fd, path);
> buf = alloca(len + 1);
> (void) snprintf(buf, len + 1, "/proc/self/fd/%d/%s", fd, path);
>
> if (flag == SYMLNK) {
Erm... IMO this is wrong, e.g. |flags| should contain set of flag _bits_
and setting unknown bits should return an error.
> return (lchown(buf, owner, group));
> else {
> return (chown(buf, owner, group));
> }
> }
But that's not portable (and it looks more or less like the other
workaround of keeping the current working directory's name around and
concaternate that with the relative path provided as argument (and
that's not really a good idea, for example if a dir looses it's parent
this workaround will no longer work (and may be a problem if the base
path is near |PATH_MAX| (your solution will still work but will still
not be portable)))) ... ;-(
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) [EMAIL PROTECTED]
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
