Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:45587
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain latitude-51.co.uk designates 80.235.207.146 as permitted sender)
Message-ID: <8EBCCF3B6859465A8B7AFCD8B9459A0C@saturn>
To: "Keisial" <keisial@gmail.com>
Cc: <internals@lists.php.net>
References: <3A8BE18A46C746E69582175E92E503AC@saturn> <4AB221F6.1070504@gmail.com> <1545DFB6BD704A44A4CB7C1B6EF3B5D1@saturn> <4AB23175.1080601@gmail.com>
Date: Thu, 17 Sep 2009 14:11:21 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Detecting share violations over cifs with PHP? Feature request
From: ian.tighe@latitude-51.co.uk ("Ian Tighe")

Yes readdir was an example and I am saying error reporting is not very good.
I am suggesting ( requesting a feature ) that all I/O functions should 
return better information so we can detect outcomes of I/O - whichever 
function is used, whatever file system, whatever circumstance.

----- Original Message ----- 
From: "Keisial" <keisial@gmail.com>
To: "Ian Tighe" <ian.tighe@latitude-51.co.uk>
Cc: <internals@lists.php.net>
Sent: Thursday, September 17, 2009 1:54 PM
Subject: Re: [PHP-DEV] Detecting share violations over cifs with PHP? 
Feature request


> Ian Tighe `wrote:
>> Hi ,
>> I am using readdir with a view to selecting files for opening and
>> reading or just taking a stat of them. I am doing this recursively. I
>> test the output from readdir to see if its a file or dir or link etc
>> and this works well. This suddenly changes though and an item is
>> returned by readdir (that is a filename) but its type cannot be
>> determined - it is not of any type at all! So looking at a wireshark
>> trace revealed there had been a sharing violation but I was blissfully
>> unaware of this.
>>
>> I am seeking to have such an error condition made available so that
>> ANY i/o op can be tested not just for true or false but to further
>> establish the i/o outcome and hence track sharing violations amongst
>> other errors. Apart from the type issue above, my substantive point
>> about readdir was this: If I get a false reply I am not sure if I had
>> a failed i/o operation or I had come to the end of a directory list.
>> As far as I can see ( and I may be wrong of course ) there is for PHP
>> no difference between the two but the impact is significantly
>> different. It was more to demonstrate that error reporting is fairly
>> clumsy in these circumstances.
> The readdir() system call doesn't have a better error checking. It will
> return a null pointer on error, just as on eof. The only way to check if
> it had an error is by setting errno to 0 before the call and checking
> its status after it. And the reported shouldn't happen anyway, since
> they are application errors (passing a bad fd...) not reading problems.
>
> Perhaps the sharing violation should be reported by stat() instead of
> readdir()?
>
>> It is certainly true all the files I have seen so far that cause this
>> problem related to either iTunes or Microsoft - especially internet
>> explorer 8 recovery files. It must be they are exclusively locked and
>> any attempt by my software makes to read them brings about a violation
>> which cannot be detected, cannot be recovered from and thus not
>> handled by me.
>>
>> I cannot reliably repeat it as I can barely detect it other than my
>> software will carry on looking for files and directories and not being
>> able to recognise types and actions I wanted are not carried out.  I
>> have a wireshark trace of the smb protocol exchanges if that helps but
>> it basically says trans2 query path request, trans2 query path
>> response , create_andx request (which is probably a stat), which is
>> retried several times and finally a create andx response indicating a
>> sharing violation. If I could get hold of that in PHP I could
>> react.............
>> Thanks
>> Ian
>
>