Re: Strange behavior from unlink() Unix-type API

We've recently noticed some strange goings-on with the unlink() API call.

We call it (from RPG, FWIW) to delete an IFS file, and it fails.

We modified the call, so we're catching the return value, and checking
errno, and sure enough the call is failing, and errno is coming back
with 3401, "EACCESS."

And the owner/creator can't delete it from the command line, either.

Looking at the authority on the IFS file, we find that, for some reason,
the creator/owner has no object authority, but *PUBLIC has *ALL object
authority.

Now, I've done some things (an ownership change, as I recall, and I
think it's to the group profile) to protect the files we're talking
about from being deleted inadvertently as a result of user profile
deletion, but I can't imagine how that ownership change would result in
the owner of an IFS file being locked out.

On closer examination, I see that the ownership change is *not*
happening in the affected directory, yet it apparently *is* happening in
another environment's IFS directory. And in the directory where it's
working properly, the group profile owner is retaining full rights to
it. This just keeps getting weirder.

Anybody have any insights here?

--
JHHL