On Mon, 2019-03-04 at 14:18 +0000, Wei Liu wrote: > CC Ian as well. > > It would be better if you run ./scripts/get_maintainers.pl on your > patches in the future to CC the correct people.
Will do; thanks. > On Fri, Mar 01, 2019 at 12:16:56PM +0000, David Woodhouse wrote: > > From: David Woodhouse <[email protected]> > > > > When recursing, a node sometimes disappears. Deal with it and move on > > instead of aborting and failing to print the rest of what was > > requested. > > > > Signed-off-by: David Woodhouse <[email protected]> > > --- > > And thus did an extremely sporadic "not going to delete that device > > because it already doesn't exist" failure mode become painfully obvious > > in retrospect... > > > > diff --git a/tools/xenstore/xenstore_client.c > > b/tools/xenstore/xenstore_client.c > > index 3afc630ab8..c089d60a2a 100644 > > --- a/tools/xenstore/xenstore_client.c > > +++ b/tools/xenstore/xenstore_client.c > > @@ -153,8 +153,13 @@ static void do_ls(struct xs_handle *h, char > > *path, > > int cur_depth, int show_perms > > err(1, "malloc in do_ls"); > > > > e = xs_directory(h, XBT_NULL, path, &num); > > - if (e == NULL) > > - err(1, "xs_directory (%s)", path); > > + if (e == NULL) { > > + if (!cur_depth) > > + err(1, "xs_directory (%s)", path); > > + > > + /* If a node disappears while recursing, silently move on. > > */ > > + num = 0; > > + } > > Can you check if the errno is ENOENT? I would rather not ignore other > types of errors if possible. Under what circumstances is it correct for xenstore-ls to abort immediately and not attempt to print anything more? I'm sure there are circumstances where the world is so hosed that it'll keep getting errors and *fail* to print anything more. But to deliberately bail out? Should that really be restricted to ENOENT?
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
