If you are referring to 'umask u-x,g=x,o+w', this removes execute
permission for the owner ('user'), adds write permission for 'others'
and sets the group permissions to be only the execute permission,
removing any others. IOW, the executable bit is set for the group and
all other group permis
It works as I would have expected now.
David Ashley
On Sun, 2013-12-15 at 15:50 +0100, Uli Zinngrebe wrote:
> On Saturday 14 Dec 2013 18:12:11 Rick McGuire wrote:
> > Ok, the fix has been committed to both trunk and branch. Someone needs to
> > check this out on a non-Windows system.
> >
>
> F
On Saturday 14 Dec 2013 18:12:11 Rick McGuire wrote:
> Ok, the fix has been committed to both trunk and branch. Someone needs to
> check this out on a non-Windows system.
>
File permissions now adapt to umask settings.
In the second example I'm not sure whether umask means
- that the execut
Ok, the fix has been committed to both trunk and branch. Someone needs to
check this out on a non-Windows system.
Rick
On Sat, Dec 14, 2013 at 6:00 PM, Mark Miesfeld wrote:
> On Sat, Dec 14, 2013 at 2:52 PM, Rick McGuire wrote:
>
>> I think a fix for this is pretty simple,
>>
> ...
> ...the
On Sat, Dec 14, 2013 at 2:52 PM, Rick McGuire wrote:
> I think a fix for this is pretty simple,
>
...
...the big remaining question is whether we should be setting the other
flag as well. Assuming umask() is actually doing what I think it is, then
I believe the answer is yes. Do other agree?
I think a fix for this is pretty simple, although there is some cleanup
required for the stream code to use it properly. It appears this was
thought of back when the 4.0 restructure was originally done, but was not
properly implemented. SysFile.hpp defines a pair of constants for
RX_S_IWRITE and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
The open documentation states the following:
mode specifies the permissions to use in case a new file is cre?
ated. This argument must be supplied when O_CREAT is specified
in flags; if O_CREAT is not specified, then mode is ign
> While you argument is somewhat true, Linux is used as a
> server operating system more that a single user computer.
Ah .. good point.
Mike
--
Rapidly troubleshoot problems before they affect your business. Most I
Well good.
Seem counter-intuitive at first glance. I'm glad you read the docs.
--
Mark Miesfeld
On Thu, Dec 12, 2013 at 2:42 PM, Rick McGuire wrote:
> If I'm reading the docs for umask correctly, the right fix is the easy
> fix. If we set the other bits on, the process umask setting will t
If I'm reading the docs for umask correctly, the right fix is the easy fix.
If we set the other bits on, the process umask setting will take take of
turning the inappropriate flags off again.
Rick
On Thu, Dec 12, 2013 at 3:46 PM, David Ashley wrote:
> The problem is that the file open call unc
On Thu, Dec 12, 2013 at 1:08 PM, Rick McGuire wrote:
> I suspect we need to be doing the right fix rather than the easy fix.
>
I agree, the easy fix seems worse than the current behavior. What if the
user doesn't want others to be able to read the file. Better the user has
to manually interven
I suspect we need to be doing the right fix rather than the easy fix.
Rick
On Thu, Dec 12, 2013 at 3:46 PM, David Ashley wrote:
> The problem is that the file open call unconditionally set a permission
> of 0600 which only gives the owner rw permissions. Here is the strace
> for the call which
t Rexx Developer Mailing List
> Subject: Re: [Oorexx-devel] Bug or Not?
>
>
>
> Never even realized we were responsible for applying stuff
> like that. Would have thought the system would have been
> handling that. In
The problem is that the file open call unconditionally set a permission
of 0600 which only gives the owner rw permissions. Here is the strace
for the call which was caused by a lineout function call which opened a
new file.
open("/ibm/tci/data/lodb/requests/crackdispo-testlot-1234567-2013-12-12-11
(and the like) are in a sense even more dated .. but a better
solution :-).
Mike
_
From: Rick McGuire [mailto:object.r...@gmail.com]
Sent: 12 December 2013 20:09
To: Open Object Rexx Developer Mailing List
Subject: Re: [Oorexx-devel] Bug or Not?
Never even realized we were
Never even realized we were responsible for applying stuff like that.
Would have thought the system would have been handling that. In any
event, I think I agree we need to fix that, although given nobody has
complained about it before this, I'm not sure I'd agree it needs to be
fixed ASAP. In an
All -
I cannot believe I have been using ooRexx on Linux for about 10 years
and I just had something pointed to me by a user that I have never
noticed before.
When ooRexx creates a file on *nix that file is created with the
permissions -rw--- which means that only the owner can read and
write
17 matches
Mail list logo
