Re: [9fans] p9p: 9 ls /dev

Hello David, thanks for the response. > it may not be worth it I agree. I think it is wise to give up to simulate dirread() rigorously. plan9 is not unix. > Ori's suggestion to use Getdirentries64 on OSX might be better I cannot find getdirentries64() on my OSX. I examined david code and

Re: [9fans] p9p: 9 ls /dev

The problem is twofold; * The function exits early if it can't read a max-length directory entry, so that entry is "skipped" in subsequent calls to mygetdents. * As you said, we also lose any buffered dirents that haven't been returned from readdir yet. I think these are both fixable problems,

Re: [9fans] p9p: 9 ls /dev

I did more test on david code and found a problem. -bash$ mk -f mkfile_david -bash$ o.test_dirread -a /usr/bin |wc 10844336 27266 -bash$ o.test_dirread /usr/bin |wc 10844336 27266 -bash$ ls /usr/bin |wc 110811089719 option -a is for dirreadall. 1108 - 1084 entries

Re: [9fans] p9p: 9 ls /dev

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

Re: [9fans] p9p: 9 ls /dev

Ignore my previous post, I was tired and forgot about dup(). How about something like this? (attached) 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

Re: [9fans] p9p: 9 ls /dev

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. It

Re: [9fans] p9p: 9 ls /dev

On Sat, 8 Apr 2017 15:21:47 +0900, arisawa wrote: > but how to? > > unix doesn’t 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). > > readdirall() might be

Re: [9fans] p9p: 9 ls /dev

but how to? unix doesn’t 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). readdirall() might be OK in regular usage. > 2017/04/08 13:06、Lyndon Nerenberg のメール： >

Re: [9fans] p9p: 9 ls /dev

> On Apr 7, 2017, at 6:18 PM, arisawa wrote: > > the problem comes from getdirentries() used in $P9P/src/lib9/dirread.c, I > think. > > man getdirentries(2) of OSX says: And, dare I quote a Linux manpage, but getdirentries(3) there says: > CONFORMING TO >Not in

Re: [9fans] p9p: 9 ls /dev

thanks for response. the problem comes from getdirentries() used in $P9P/src/lib9/dirread.c, I think. man getdirentries(2) of OSX says: NOTES getdirentries() should rarely be used directly; instead, opendir(3) and readdir(3) should be used. As of Mac OS X 10.6, getdirentries()

Re: [9fans] p9p: 9 ls /dev

> On Apr 6, 2017, at 5:49 AM, arisawa wrote: > > on my system (on osx(10.10 and 10.11) with plan9port-20140306 (latest port > from russ)) > the next command fails. that is, > 9 ls /dev > does not return to shell. It also hangs on my 10.12.4 system. Mind you, I haven't