HTCondor Project List Archives



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Condor-devel] changes to condor_submit



On 08/05/2010 08:09 PM, Peter Keller wrote:
On Thu, Aug 05, 2010 at 04:58:06PM -0700, Rob wrote:
On Thu, 05 Aug 2010 14:56:09 Dan Bradley wrote:
The problem appears to be from this line in file_transfer.cpp:

+                       if ( ! access(ExecFile,F_OK | X_OK)>= 0 ) {
+                               free(ExecFile); ExecFile = NULL;

Is "access(ExecFile,F_OK | X_OK)" correct?
I think there's at least some redundancy there...


On my Fedora system, 'man access' says:


int access(const char *pathname, int mode);
   [...]
   The mode specifies the accessibility check(s) to be
   performed, and is either the value F_OK, or a mask
   consisting of the bitwise OR of one or more of R_OK,
   W_OK, and X_OK.
   [...]
   On  success  (all requested permissions granted),
zero is returned.


So, "F_OK | X_OK" seems to be redundant!

The ZERO return on SUCCESS I did not realized in the past
and occasionally wrote buggy code....


Please double check that this access() if-conditional-clause
really does what it's suppose to do!

Um, is that actually access()? Or access_euid()? If the latter, then
you know why I have "obscure knowledge maintainer" on my business card. :)

Later,
-pete

http://condor-git.cs.wisc.edu/?p=condor.git;a=blob;f=src/condor_includes/condor_fix_access.h

"obscure knowledge maintainer" =?= "You think you know something about POSIX, well I bet I can trick you."

8oP

This one has been on my hit list for a very long time. Patches welcome to eliminate cognitive debt.

$ git grep "access\W*(" | grep -v _access | wc -l
59

Including, from src/condor_syscall_lib/switches.special.cpp, this gem,

/* get rid of the remapping of access() to access_euid() since system calls
   generally should be what they actually should be, and not what we think
   they should be. */
#ifdef access
# undef access
#endif


Best,


matt