On Mon, Feb 27, 2012 at 01:54:49PM +1030, Brett Lymn wrote:
> > I don't think any of those is the right answer. Coda is not limited to
> > running on top of ffs, so it shouldn't be doing only filesystem-
> > independent things when talking to the filesystem it uses for storage.
> > (Right?)
>
hi,
>> (I'll check the other issues you pointed out ASAP)
if an error happens between execve_loadvm and execve_runproc,
who frees what execve_loadvm allocated?
(ed_argp, ep_fd, ep_vp, vmcmds,...)
the error_exit: path seems to leak p_reflock and spawn_data.
exec_lock still seems deadlock-prune.
On Mon, Feb 27, 2012 at 02:43:51AM +, David Holland wrote:
>
> I don't think any of those is the right answer. Coda is not limited to
> running on top of ffs, so it shouldn't be doing only filesystem-
> independent things when talking to the filesystem it uses for storage.
> (Right?)
>
Right
On Mon, Feb 27, 2012 at 10:55:48AM +1030, Brett Lymn wrote:
> I have been tracking through a bug with Coda where, basically, getdents(2)
> is not returning all the directory entries. The files exist in the
> directory but do not show up on a globbed listing. After some digging I
> found that
I have been tracking through a bug with Coda where, basically, getdents(2)
is not returning all the directory entries. The files exist in the
directory but do not show up on a globbed listing. After some digging I
found that things ended up in ufs_readdir() which was terminating early
due to a b
