×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
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
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact
[javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
