Re: Re: Test failure on MacOS X and Failure analysis

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.