Re: Equivalent of openat() on osx?
Re: Equivalent of openat() on osx?
- Subject: Re: Equivalent of openat() on osx?
- From: Anatol Pomozov <email@hidden>
- Date: Tue, 03 May 2011 13:46:54 -0700
Hi
On Tue, May 3, 2011 at 11:34 AM, Paul Nelson <email@hidden> wrote:
>
> On May 3, 2011, at 12:45 PM, Tilghman Lesher wrote:
>
>> On Tuesday 03 May 2011 11:13:09 Anatol Pomozov wrote:
>>> I am porting a Linux program to macosx (target is 10.6 version) and
>>> the program uses openat/unlinkat/... functions. Although these
>>> functions are not in POSIX, they are widely used on *nixes and the
>>> part proposal the next POSIX.
>>>
>>> My question what is the best equivalent for the opentat() functions
>>> that can be used in multithreaded application. Currently I use
>>> something like this:
>>>
>>>
>>> int openat(int dirfd, const char *pathname, int flags, ...)
>>> {
>>> int fd;
>>>
>>> if(fchdir(dirfd) < 0) {
>>> perror("fchdir");
>>> return -1;
>>> }
>>> fd = open(pathname, flags, mode);
>>> // chdir to the original CWD
>>> return fd;
>>> }
>>>
>>> But this is not a perfect solution - current working directory is
>>> shared among all threads, it means that openat() may affect other
>>> threads. Is there an equivalent of this implementation without
>>> changing the current directory?
>>
>> If you aren't using chroot(2) (or moving directories) in your application,
>> you can do this. Wrap calls to opendir(2) and closedir(2), mapping
>> descriptors to directory paths (and disposing of them), then in your *at()
>> functions, remap the relative pathname back to an absolute pathname.
>> You're right that this isn't a perfect compromise, but I think it should
>> work, with the caveats above.
>
> This is exactly what openat is supposed to avoid. You don't want to use a path that is stale in the open call. If you are using openat, you probably have a reason for it. The directory fd passed in might get renamed before the open can be called.
> I think the poster was on the right track with fchdir, assuming they also use open(".", O_RDONLY,0) to save the current wd. This will guarantee that the folder does not disappear before the open call happens. I would use pthread mutexes to protect the fchdir stuff, and you might consider something more sophisticated when you receive a blocking open call so the mutex doesn't get held too long. Also, avoid using getcwd, as it is a performance pig.
Thanks Paul for the open&fchdir suggestion, initially I was using
getcwd&chdir. Here is the new version
https://github.com/anatol/tup/blob/fix_openat_macosx/src/compat/openat.c
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden