Hi Steinar- Steinar H. Gunderson wrote: > Hi, > > As per a bug report from a user: > > mount.c seems to assume that nfsumount() uses standard C true/false > return values, and inverts them for the exit status (where 0 is > traditionally considered success). However, nfsumount() consistently > seems to use 0 for success, and thus a success gets returned as exit > status 1 and a failure as exit status 0. This confuses at least > the GNOME drive manager applet, and probably others as well. > > Signed-off-by: Steinar H. Gunderson > > Index: nfs-utils-1.1.0/utils/mount/mount.c > =================================================================== > --- nfs-utils-1.1.0.orig/utils/mount/mount.c > +++ nfs-utils-1.1.0/utils/mount/mount.c > @@ -371,7 +371,7 @@ int main(int argc, char *argv[]) > umount_usage(); > exit(1); > } > - exit(nfsumount(argc, argv) ? 0 : 1); > + exit(nfsumount(argc, argv)); > } > > if(argv[1] && argv[1][0] == '-') { > > /* Steinar */ Reviewing the NFS umount return path, I see other problems: 1. nfsumount.c does not contain the string "EX_" which means it doesn't use the normal mount error return codes (and it probably should?). For example, del_mtab() should return EX_FILEIO on error. The use of improper umount options should return EX_USAGE. A failure or negative result of the MNT RPC call should return EX_FAIL. 2. _nfsumount returns an integer result which is ignored by it's only caller. If the result truly doesn't matter (which I doubt), then _nfsumount should return void; otherwise the caller should be fixed to return _nfsumount's return code. 3. nfs_call_umount returns an integer, but appears to be confused about whether one is success or zero is success. In fact, it returns the value of "res" which is an enum clnt_stat, not a valid mount return code. 4. There is one place where nfsumount.c needlessly uses exit(1) instead of returning. I agree with removing the logic you eliminated, but more needs to be done in nfsumount.c to make this a complete fix.