RE: Strange behavior from unlink() Unix-type API -- MIDRANGE-L

Hmmm... Guess I'll have to concede that - I agree it is quite clear.

This is different, though, from what I remember about unix type standards.
But even so - and whether the i doesn't follow that standard or I just
misremember - that doesn't mean you didn't read the documentation properly.
My apologies.

Dennis Lovelady
http://www.linkedin.com/in/dennislovelady
--
"Abstract Art: A product of the untalented, sold by the unprincipled to the
utterly bewildered."
-- Al Capp

Am I? The table that I was referencing is labeled as follows:

Figure 1-77. Authorization Required for unlink() (excluding QSYS.LIB,
independent ASP QSYS.LIB, QDLS and QOPT)

Maybe I'm looking at different documentation, but it seems pretty clear...

-Eric

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx]
On Behalf Of Dennis
Sent: Tuesday, August 16, 2011 1:52 PM
To: Midrange Systems Technical Discussion
Subject: Re: Strange behavior from unlink() Unix-type API

Anyway, I believe Eric is misreading the documentation at the link he

supplied.

There is definitely no need to have permissions at any directory above
the directory containing the file to be unlinked. If it is a UDF
object, then you must, but otherwise that is not necessary. One also
doesn't need Execute (X) permissions to that directory in order to use
unlink. One needs Execute permissions in order to chdir() into that

directory.

If I have Read and Write permissions to a directory, I can add and
remove files all day long. Even if I have no permissions to the

directory's parent.

++
Dennis
++

Sent from my Galaxy tablet phone. Please excuse my brevity.
For any grammatic/spelling errors, there is no excuse.
++

"James Lampert" <jamesl@xxxxxxxxxxxxxxxxx> wrote:

DeLong, Eric wrote:

James, did you ever read the link that I posted earlier? I suspect
you're still NOT checking the directories in the path that precede
your file object. EACH of the directories in your path MUST have
at minimum *X, the directory that contains your file must have *WX,
and the file object itself must all *OBJEXIST authority...

Uh, (1) the directories that always behaved properly were direct
sister-directories to the one that was malfunctioning, i.e., in the
same immediate parent directory, so path could not have been
involved, and
(2) in the malfunctioning directory, the owners of all files created
after it began malfunctioning were explicitly locked out of object
authorities for their files, and (3) the malfunctioning directory had
no authority line at all for the owner, and as soon as I added one,
it started behaving properly.

The only question remaining is how the owner's authority line for the
malfunctioning directory disappeared in the first place, and why its
absence would cause everything created therein to be created with an
owner authority line explicitly locking out the owner's object
authorities.

--
JHHL
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L)
mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To
subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take
a moment to review the archives at
http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take
a moment to review the archives at
http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take
a moment to review the archives at
http://archive.midrange.com/midrange-l.