Hi Tony

The filesystem tests are diffficult and require some compromises - it isn't easy to work out exactly where.

If we change tests so that they pass on as many OS as possible, for example by changing %d to %i, we'll be relaxing some of the strictness of the test. If we do this the functional ref should make it very clear that behaviour is OS dependent and that PHP is essentially just using the underlying OS function and passing back whatever it gets.

The only problem with that is we will be failing to test that PHP really does pass back what is expected for each OS. For example the behaviour of stat() on Linux/VMware was (if I understood it correctly) a PHP problem which we only found by coding the exact behaviour that was expected on Linux.

What is the most widely used platform? I always assume that it's Linux but don't know if that's correct. What about having a strict set of tests that were specific to Linux (or specified versions of Linux) and a less strict version of the same tests that are designed to do some level of checking (eg %i) on all OS? That would be two sets (I don't think a set for each OS is realistic either).

Zoe

Antony Dovgal wrote:
On 26.06.2007 22:23, Raghubansh wrote:
Explanation:
------------
There is a difference in the size of a dir when created. On Linux its is
4096 by default but
on MacOS its 68 and then changes when a new file/subdir is created inside
the dir. I suggest that we
have seperate testcase for MacOs or just do the check for %d or %i in place
of size.

I guess the latter would be the best choice, cause we don't want to create a separate test for each OS/filesystem.

Explanation:
------------
The behavior of popen() is expected to be saying "Invalid argument ...." but
looks like it
tried to proceed with the given wrong input and finally fails. I think this
looks like a bug,
If you agree I'll raise bugzilla.

Different systems return different error messages in some cases, that happens and we have to live with that.

The failure on line number 35  is coming from realpath().
The expected output is bool(false) because given path is invalid and
nonexistent.
I think this looks like a bug, If you agree I'll raise bugzilla

The failure on line number 41 & 67, The given path is
correct but since it end with a forward slash, it should be treated as dir
and hence non-existing
The function seems to not behave correctly. I think this looks like a bug,
If you agree I'll raise bugzilla.

No, we have to adopt tests for that, that's expected behaviour on MacOS.

Explanation:
------------
The failure is coming from realpath with nonexistent file. The expected
output should be bool(false)
where as here the realpath returns the given input as output. I think this
looks like a bug,
If you agree I'll raise bugzilla

Expected on MacOS.

Explanation:
------------
Here both the failure as coming because of " " and ' ' being passed to
realpath. The expected
behaviour should be bool(false) because given path doesn't exist. I think
this looks like a bug,
If you agree I'll raise bugzilla.

MacOS problems, not PHP.

Explanation:
------------
Here the failures( line no 9, 12 & 15) come from symlink() with first
argument supplied as : NULL, '' & false
The output on Linux and MacOS are not similar, I think the output should be
consistent. If you agree I'll raise bugzilla.

Ditto for this one.

Explanation:
------------
There two thing in the failure.

1. We see that the temp dir created by the tests already exists, may be not
cleaned
by previous tests ( i.e symlink_link_linkinfo_is_link.basic/error.phpt ).
The code pretty much there to
clean the dir created but looks like there could be problem, Please could
you run only these three tests and let us
know the result , in case of failure, pls provide diff file and output of
command "ls -l" on the dir where test is run
  files are( please run the below sequnce only):
     symlink_link_linkinfo_is_link_basic.phpt
     symlink_link_linkinfo_is_link_error.phpt
     symlink_link_linkinfo_is_link_variation.phpt

2. The other failure here is because of the directory permission is not
respected by symlink() and link command.
When the dir doesnot have permission to create a file inside it, the
symlink() and link() are still
creating the files in it. I think this looks like a bug, If you agree I'll
raise bugzilla

Yet another MacOS weirdness/problem, we can't fix that without reimplementing whole OS.


--
PHP CVS Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to