On Thu, Jan 8, 2015 at 11:17 AM, Josef 'Jeff' Sipek via illumos-developer < [email protected]> wrote:
> Please review: > > Bug: https://www.illumos.org/issues/5515 > Webrev: > http://31bits.net/illumos/cr/5515-dataset-user-hold-doesnt-reject-empty-tags/ LGTM. > > Patch: > http://repo.or.cz/w/illumos-gate/jeffpc.git/patch/86e8d34e994c9f247014b92a0f88de261a170a46 > > This patch causes the hold ioctl handler to return EINVAL in one of two > cases: > > (1) the hold tag is empty (new) > (2) user wanted to put a hold on something that's not a snapshot (existing) > > Sadly, the ioctl return value makes its way to libzfs (zfs_hold_nvl), which > does what libzfs does - prints an error message. > > > http://src.illumos.org/source/xref/illumos-gate/usr/src/lib/libzfs/common/libzfs_dataset.c#4305 > > It of course assumes that we got an EINVAL because of case #2 and so the > user sees: > > "operation not applicable to datasets of this type" > > This is quite misleading. My best idea is to add a empty-tag check to > libzfs. Any better ideas? > That's probably the idiomatic thing to do. --matt > > Since the error message is a rather minor cosmetic issue, I'm hoping to not > delay the assertion failure preventing fix in the ioctl handler because of > it. > > > These changes can be pulled via: > > $ git pull git://repo.or.cz/illumos-gate/jeffpc.git zfs-hold > > > Thanks, > > Jeff. > > >
_______________________________________________ developer mailing list [email protected] http://lists.open-zfs.org/mailman/listinfo/developer
