On Fri, Jan 17, 2014 at 1:17 PM, Paul B. Henson <[email protected]> wrote:
> So, zfs get ignores a leading / in a dataset name: > Technically, it allows you to specify a file path. If you are using the default mountpoints, this is the same as the dataset name with a leading slash. See the ZFS_ITER_ARGS_CAN_BE_PATHS flag to zfs_for_each() for details. > > root@storage ~ # zfs get sharenfs /export/media > NAME PROPERTY VALUE SOURCE > export/media sharenfs off default > > Whereas zfs set does not: > > root@storage ~ # zfs set sharenfs=on /export/media > cannot open '/export/media': invalid dataset name > > This seems a bit inconsistent? Personally, I'd prefer they both ignore a > leading /, as that makes it easier to tab complete from a shell prompt, > but either way, I think it should be consistent. > My concern with allowing file paths for "zfs set" would be that you might think you are setting the property on the specified directory or file, when in fact you are setting it for the whole filesystem. E.g. "zfs set compress=on /export/media/pdfs" actually enables compresson on /export/media/jpgs too, if they are in the same filesystem. Maybe we could add some new functionality to allow filesystem mount points to be specified (but not any file or directory). This way "zfs set ... /export/media/pdfs" would fail but "zfs set ... /export/media" would succeed. --matt > > Thoughts? This is latest omnios stable btw, but I don't think the > behavior has changed. > _______________________________________________ > developer mailing list > [email protected] > http://lists.open-zfs.org/mailman/listinfo/developer >
_______________________________________________ developer mailing list [email protected] http://lists.open-zfs.org/mailman/listinfo/developer
