From mboxrd@z Thu Jan  1 00:00:00 1970
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: arisawa <karisawa@gmail.com>
In-Reply-To: <1491642434.3078770.938277904.69229AAA@webmail.messagingengine.com>
Date: Sun,  9 Apr 2017 13:18:11 +0900
Content-Transfer-Encoding: quoted-printable
Message-Id: <01A91DF6-C9BC-46FD-85EE-A978410FDAB1@gmail.com>
References: <167A2E66-33F8-4909-8FDB-06F92E930D8B@gmail.com>
	<795C88A6-B6FE-4B29-AD74-50A0E4D80D97@orthanc.ca>
	<6C339BCD-FF90-4C03-9AC9-D4098E63EDD8@gmail.com>
	<789A602E-FC47-40AE-96F4-64E2D2A5B375@orthanc.ca>
	<4B168609-E25A-4D3C-9A80-1457BA0EE830@gmail.com>
	<20170407234654.40b4e23976d220cea4ab3daf@eigenstate.org>
	<1491636459.3063398.938223400.7B35C566@webmail.messagingengine.com>
	<1491642434.3078770.938277904.69229AAA@webmail.messagingengine.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] p9p: 9 ls /dev
Topicbox-Message-UUID: b97e52d4-ead9-11e9-9d60-3106f5b1d025

thanks david.

using dup() is very nice idea!
your code works with
   CFLAGS=3D-D__DARWIN_64_BIT_INO_T		# manual is wrong
and a fix:
//	buf =3D ((char*)buf) + d_reclen(buf);
	buf =3D (struct dirent *)(((char*)buf) + d_reclen(buf));
and adding
	#define NAME_MAX 256
in somewhere.

now /dev is readable.

one problem is left.

my test code:
	fd =3D open(dirname,OREAD);
	if(fd < 0)
		fatal("%s open error",dirname);
	while((n =3D dirread(fd, &db)) > 0){
		print("#DBG n=3D%d\n",n);
		for(i =3D 0; i < n; i++)
			print("%s %s %s \n", db[i].name, db[i].uid, =
db[i].gid);
	}
	close(fd);
shows for dirname=3D$HOME
	...
	arch root 501=20
	bin root 501=20
	...
but they should be
	arch arisawa staff=20
	bin arisawa staff
 this problem comes from _p9dir() that is used in dirpackage().

Kenji Arisawa


> 2017/04/08 18:07=E3=80=81David Arroyo <droyo@aqwari.net> =
=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=EF=BC=9A
>=20
> Ignore my previous post, I was tired and forgot about dup(). How about
> something like this? (attached)
>=20
> I only tested this on Ubuntu, I don't have an OS X machine. I still =
went
> with readdir_r because the AIX and Solaris man pages for readdir were
> vague about its behavior when called from multiple threads (glibc, =
musl,
> FreeBSD look pretty safe).
>=20
> Cheers,
> David
>=20
> On Sat, Apr 8, 2017, at 03:27 AM, David Arroyo wrote:
>> This should be doable with some combination of fdopendir(3) and
>> readdir(3). I'm not sure how to avoid leaking memory through the
>> returned DIR pointer and any memory allocated with by readdir(3).
>> This is usually free'd by closedir(3), which we can't use without
>> closing the underlying file.
>>=20
>> It should be OK to use free() on the return value of fdopendir, and
>> stick to the uglier readdir_r(3) interface. I can definitely see why
>> Russ went with  the simpler  system-specific interfaces on this.
>>=20
>> David
>>=20
>> On Sat, Apr 8, 2017, at 02:46 AM, Ori Bernstein wrote:
>>> On Sat, 8 Apr 2017 15:21:47 +0900, arisawa <karisawa@gmail.com> =
wrote:
>>>=20
>>>> but how to?
>>>>=20
>>>> unix doesn=E2=80=99t have something like fdreaddir(int fd).
>>>> my guess: russ unwillingly used a low level function such as
>>>> int getdirentries(int fd, char *buf, int nbytes, long *basep).
>>>>=20
>>>> readdirall() might be OK in regular usage.
>>>=20
>>> I don't use OSX regularly, although I do maintain the syscall
>>> layer for Myrddin on it.
>>>=20
>>> Getdirentries64 exists, and rudimentary testing doesn't show
>>> any difficulties with using it.
>>>=20
>>> --=20
>>>    Ori Bernstein
>>>=20
>>=20
> <posix-dirread.patch>