On Fri, May 11, 2018 at 05:06:34PM -0700, Darrick J. Wong wrote: > On Fri, May 11, 2018 at 12:26:51PM -0700, Mark Fasheh wrote: > > Right now we return EINVAL if a process does not have permission to dedupe a > > file. This was an oversight on my part. EPERM gives a true description of > > the nature of our error, and EINVAL is already used for the case that the > > filesystem does not support dedupe.
> > - info->status = -EINVAL; > > + info->status = -EPERM; > > Hmm, are we allowed to change this aspect of the kabi after the fact? > > Granted, we're only trading one error code for another, but will the > existing users of this care? xfs_io won't and I assume duperemove won't > either, but what about bees? :) There's more: https://codesearch.debian.net/search?q=FILE_EXTENT_SAME This includes only software that has been packaged for Debian (notably, not bees), but that gives enough interesting coverage. And none of these cases discriminate between error codes -- they merely report them to the user. Thus, I can't think of a downside of making the error code more accurate. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢰⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ Certified airhead; got the CT scan to prove that! ⠈⠳⣄⠀⠀⠀⠀ -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
