On Sat, Nov 12, 2011 at 11:34 AM, Jean-Louis Faucher
<jfaucher...@gmail.com>wrote:

> Thanks Mark
>
> You're right, I will split the method in several methods, and make it work
> under Windows. The test \== "Windows" was already used in this file for one
> test, where chmod is used. I took it as a model, that was exactly what I
> needed :-).
>


Jean-Louis,

No real problem there, but as an explantion.  (I wrote the test case with
chmod in it.)

-- Test state equals ERROR.  On Linux / Unix this test case will fail if run
-- by root.  So, we check for root and if so fail the test case.
::method test_state_error
  fileName = "delMe.testingFilec"
  discard = stream(fileName, 'C', "open shared")
  do i = 1 to 9
    discard = lineout(fileName, 'My line' i)
  end

  f = .stream~new(fileName)
  self~assertTrue(f~isA(.stream))
  self~streamTestingFile = f

  if .ooRexxUnit.OSName \== "WINDOWS" then do
    cmd = 'id -u > /dev/null 2>&1'
    output = .array~new
    ret = issueCmd(cmd, output)
    self~assertSame(0, ret, 'Check for root must succeed')
    userID = output[1]
    self~assertNotSame(0, userID, 'This test case must not be run as root')
    'chmod -w' fileName
  end

  f~open("write replace")
  self~assertSame("ERROR", f~state)


The real test here is this:

f~open("write replace")
self~assertSame("ERROR", f~state)


and it executes no matter what the current OS is.  The test was to see that
the state() method returned "ERROR" when it should be in an error
condition.  Everything before f~open() is set up.

If you look, the file is first created (and opened) using the stream()
function.  Then it is not closed.  So, that was trying to set things up so
that after open(), state() should return "ERROR"

Works great on Windows, even if you are administrator.  But, on Linux and I
assume other *nix systems, if you are root the open succeeds, if you are
not root the open fails.

So, testing if the OS is Windows, is not to skip the test case altogether.
It is to be sure the set up is correct for the real test.

A subtle difference, but an important one.  <grin>

Also, reviewing that test case now, I don't think it should have the chmod
in it.  I think instead I should not have used the 'shared' option in the
original stream() function call.

I don't have a Linux system handy to test right now.  I'll have to try that
later.

As I said, the real test is that state() returns "ERROR", not 'error', not
'Error', not any other word (like 'READY'), when the Stream object *should*
be in an error state.

The best set up would be the same for all platforms.  So, either I should
have set the file to read only on all platforms, or not set it to read only
on all platforms.  I think I wrote it on Windows, the test worked.  Then at
some point I ran the test suite as root on Linux and the test did not work.




>
> Under Windows, I don't think I can have vrite-only files. Attrib can make
> a file read-only but not write-only. That doesnt forbid to run the test
> cases, it's just that the conditions of the original defect are not met.
>


That's correct about write-only with attrib.  I think the test case is good
enough, as the bug was really opened about the problem on Linux / *nix and
makes sense in that context.  The test should succeed on Windows, and it
does.  Good enough.

On Windows, I think we could set up the same conditions using ACLs, but it
would take some more effort and research.  So, I'm not pushing you to do
it.  <grin>  I don't have time to look into it now.

But, it would be interesting to attempt if I had some time.  1.) there is a
command line tool for setting ACLs in Windows, I don't remember what it
is.  So, I'd need to search for it.  2.) I'm not 100% sure that ACLs would
give us a write only file, but I think they would.  That could turn out to
be a lot of effort, that might fail anyway.

--
Mark Miesfeld
------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Reply via email to