Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!husc6!cs.utexas.edu!uunet!ficc!peter
From: peter@ficc.uu.net (Peter da Silva)
Newsgroups: comp.unix.wizards
Subject: Re: getcwd() and friends.
Message-ID: <3746@ficc.uu.net>
Date: 7 Apr 89 15:34:45 GMT
References: <3675@ficc.uu.net> <14689@rpp386.Dallas.TX.US> <811@mtxinu.UUCP> <2001@unisoft.UUCP>
Organization: Xenix Support
Lines: 40

In article <2001@unisoft.UUCP>, greywolf@unisoft.UUCP (The Grey Wolf) writes:
> Do you really mean "rather than" as "instead of"?  I like the idea of
> being able to do either/or, depending on what you wanted to do.  I mean,
> if they were "instead of", and chmod() were eliminated so that only
> fchmod remained, how would you change the mode of a file that was mode
> 000?  You wouldn't be able to O_RDWR or O_EXEC the file/directory and
> therefore couldn't gain a valid file descriptor to pass to fchmod().
> I think that the option of f() commands should remain open.

How about O_TOKEN which returns a fd you can't do anything to until you
do another open on it. Soirt of like an RMX file token or an AmigaDOS
file lock. Have to call the fd version of open something other than
fopen or fdopen, though.

This would make 'dup' into fd_open(fd, O_CLONE), where O_CLONE means
'same flags as the first fd'...

Do this cleverly enough and almost all the regular calls can actually use
the new calls... you just need to keep 'open' around so you can get the
fd in the first place:

	link(name, newname)
	char *name, *newname;
	{
		int fd;

		fd = open(name, O_TOKEN);
		if(fd >= 0)
		{
			retval = fd_link(fd, newname);
			close(fd);
		}
		else
			return -1;
	}
-- 
Peter da Silva, Xenix Support, Ferranti International Controls Corporation.

Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180.
Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.