On 10/22/2013 08:44 PM, NeilBrown wrote: > On Tue, 22 Oct 2013 10:23:14 -0500 Tony Asleson <tasleson@xxxxxxxxxx> wrote: >> The reason I chose to return values was to make sure requested operation >> actually completed requested operation. Unexporting a non-existent >> export is not considered an error and returns no indication you did >> absolutely nothing. > > Hi, > thanks makes sense - I had missed that (even though you explained it in the > patch description :-( ) > > With your patch, if asked to unexport something that wasn't exported it > would not report any error, but would exit with an error status. Is that > correct? I think I would rather have a message printed if there is an error. Correct, I only made changes for the exit status. I was trying to make changes that would be mostly invisible to end users. I have no concerns adding a printed error output too, but others may. Changing the behavior of any command line tool is potentially problematic when scripted. > So would something like this (on top of my patch) address you need, or was > there something else I missed? Yes, this should work for the unexport fs case. However, the reason my patch was a little more invasive was to ensure that both the export and unexport paths were covered. For example, if the strdup call fails in function client_init, we fail the operation and return exit value of 0. Unlikely, but just the first example I stumbled across. Thanks, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
