From bf76ced8ba0c9def50b5a890e735ee82ea097be0 Mon Sep 17 00:00:00 2001 From: Matthew Flatt Date: Sat, 1 Aug 2015 21:48:06 -0600 Subject: [PATCH] work around EPERM error from access() On OS X, it seems that access() can sometimes fail with EPERM when checking for execute permission on a file without it. I've previously seen this result when running as the superuser, but that's apparently not the only possibility; a long path may also be relevant. --- racket/src/racket/src/file.c | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/racket/src/racket/src/file.c b/racket/src/racket/src/file.c index 2c745f2d98..1209ef82f3 100644 --- a/racket/src/racket/src/file.c +++ b/racket/src/racket/src/file.c @@ -6088,12 +6088,10 @@ static Scheme_Object *file_or_dir_permissions(int argc, Scheme_Object *argv[]) } while ((ok == -1) && (errno == EINTR)); execute = !ok; - /* Don't fail at the exec step if the user is the - superuser and errno is EPERM; under Mac OS X, - at least, such a failure simply means tha the - file is not executable. */ - if (ok && (errno != EACCES) - && (uid || gid || (errno != EPERM))) { + /* Don't fail at the exec step if errno is EPERM; under Mac OS + X, at least, such a failure simply means that the file is + not executable. */ + if (ok && (errno != EACCES) && (errno != EPERM)) { l = NULL; } else { if (read)