Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51589
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain nebm.ist.utl.pt from 193.136.128.21 cause and error)
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
To: internals@lists.php.net
References: <4D7431C3.10405@sugarcrm.com>
Date: Mon, 07 Mar 2011 09:29:58 -0000
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Organization: =?utf-8?Q?N=C3=BAcleo_de_Eng=2E_Biom=C3=A9di?=
 =?utf-8?Q?ca_do_I=2ES=2ET=2E?=
Message-ID: <op.vryvb8ugidpuyk@clk-0081.clk-domain>
In-Reply-To: <4D7431C3.10405@sugarcrm.com>
User-Agent: Opera Mail/11.01 (Win32)
Subject: Re: [PHP-DEV] file streams & metadata
From: glopes@nebm.ist.utl.pt ("Gustavo Lopes")

Em Mon, 07 Mar 2011 01:15:47 -0000, Stas Malyshev <smalyshev@sugarcrm.com>  
escreveu:

> PHP file streams provide very powerful and useful abstraction layer over  
> the I/O-related functions. However, there's a group of functions which  
> are excluded from this support - namely, touch(), chmod(), chown() and  
> chgrp() - i.e., functions dealing with file metadata. This lead to  
> libraries implementing FS virtualization developing various hacks, such  
> as here:
> https://code.google.com/p/bovigo/wiki/vfsStreamDocsFilemode
> I propose to plug this hole in the stream implementation by adding a  
> handler to deal with metadata to stream handlers, such as:
>
> int (*stream_set_metadata)(php_stream_wrapper *wrapper, char *url, int  
> metatype, void *metadata TSRMLS_DC);
>
> metadata types can be:
> - access/modification time with touch() semantics or without it
> - permissions information
> - owner information by name or number
> - group information by name or number
>
> Of course, there are streams where it doesn't make sense, but there are  
> many application of streams (such as virtualizing real filesystems,  
> mocks, etc.) where this would help a lot with using streams  
> transparently inside applications.
> Any comments?

It's a good idea.

But what about getting the metadata (as opposed to setting it)? I  
understand reading most of this stuff is already covered by the stat  
handler, but what about for example NTFS/POSIX ACLs or reading reparse  
point data? It would be nice to have a way to retrieve them. One might as  
well add two handlers.


-- 
Gustavo Lopes