# [Review] Route stat() family of calls via wrapper ops. - Thread: https://externals.io/message/3848 - Original archive: https://news-web.php.net/php.internals/3848 - Started by pollita@php.net on 2003-08-10T00:27:22+00:00 - Messages: 4 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #3848 — pollita@php.net — 2003-08-10T00:27:22+00:00 URL: https://externals.io/message/3848#3848 The streams API has, since early in its introduction had the capacity to perform `stat()` family calls on files under any wrapper. In theory. What's preventing wrapper->wops->url_stat from being useful is that the code in ext/standard/filestat.c has never been routed through this layer. I've put together a patch at http://169.229.139.97/test/stat-streams.diff to accomplish this and it seems to test well with local files, local symlinks, and remote ftp files (the ftp wrapper has had a limited url_stat method waiting to be used for some months now). However, since the `stat()` related code does a little voodoo in terms of caching results and handling multiple function calls in a single do-all, I'd like to get feedback from others on its suitability. Also, this patch extends the stream_wrapper_ops structure slightly by adding an access_check() method (for `is_readable()`, `is_writeable()`, etc...) url_stat() and access_check() are both implemented in the plainfiles wrapper with this path. The ugliest part of this patch is that it requires special treatment for the plainfiles wrapper in order to deal with symlink stat calls. An alternative (and it wouldn't take much to convince me to go the other way) would be to add a parameter to the url_stat() method to indicate if the stat is a symlink_stat. Look forward to your thoughts. -Sara --- ## #3859 — Sara Golemon — 2003-08-11T18:37:08+00:00 URL: https://externals.io/message/3848#3859 > wrote: > > > […] > > If we implement url_stat() in such way, perhaps we can live without > access_check() method. > Yeah, I got to thinking that later on.... Perhaps the cleanest method would be to pass on the filestat_type directly to the url_stat method. plainfiles can then do VCWD_ACCESS, VCWD_STAT, or VCWD_LSTAT as appropriate and other wrappers can do their thing. (additionally: http, since it allows redirection, would be able to emulate the symlink layer by returning information on the initial hit, rather than following 302 redirects) The php_stat method in filestat.c can then focus on simply managing the statecache and forming the statbuf into returnable zvals. > But the point is, not all wrappers can accept > *ix-like access control scheme.. > Nor can they return full stat detail. i.e.: What's the filesize of php://stdin ? Who "owns" http://example.com/foo.html ? Last I spoke to Wez on the subject he indicated that we should just attempt to return as much information as we can and default on the rest. http:// wrapper: `is_writable()` would always return false. `is_readable()` would return true *IF* a HEAD request returned 2xx or 3xx `is_executable()` would always return false. `file_exists()` would return true if a HEAD request returned 2xx, 3xx, or 4xx (not including 404) sb values such as mtime, size, etc... would be parsable from the http-response headers, while ctime, atime, inode, uid, gid would be unknown and default to 0 (or maybe -1) ftp:// wrapper: `is_writeable()` would return true if APPE returned 2xx `is_readable()` would return true if RETR returned 2xx `is_executable()` would always return false `file_exists()` would return true if SIZE returned 2xx sb_size would be fetchable from SIZE , however all other values are not reliable on all platforms and would have to return 0. -Sara --- ## #3869 — Melvyn Sopacua — 2003-08-12T12:35:38+00:00 URL: https://externals.io/message/3848#3869 · In reply to: #3859 Hi, > Nor can they return full stat detail. i.e.: What's the filesize of > php://stdin ? Who "owns" http://example.com/foo.html ? Last I spoke to > Wez on the subject he indicated that we should just attempt to return as > much information as we can and default on the rest. > > http:// wrapper: > `is_writable()` would always return false. > `is_readable()` would return true *IF* a HEAD request returned 2xx or 3xx > `is_executable()` would always return false. > `file_exists()` would return true if a HEAD request returned 2xx, 3xx, or > 4xx (not including 404) I wouldn't agree there: http://www.example.com/file with spaces.png [1] returns invalid method: 400. I think the entire 4xx and 5xx family should return false. [1] I know the url is invalid, but if you wanna do syntax checking on urls, then you're in for a treat, especially when the url contains double-byte characters. As for 30[12], what happens when the refered document does not exist? Symlinks have a maximum number of links and return ELOOP. Does the same apply to 302 and what is the value of MAXSYMLINKS (sys/param.h) in that case? > -Sara -- Melvyn --- ## #3871 — Sara Golemon — 2003-08-12T18:36:46+00:00 URL: https://externals.io/message/3848#3871 · In reply to: #3869 > > […] > > I wouldn't agree there: > http://www.example.com/file with spaces.png [1] > > returns invalid method: 400. I think the entire 4xx and 5xx family > should return false. > *blink* Did I write that? Musta been talking to someone while I was doing it. Yes, I agree, only 2xx and 3xx should return true. > As for 30[12], what happens when the refered document does not exist? > Symlinks have a maximum number of links and return ELOOP. Does the same > apply to 302 and what is the value of MAXSYMLINKS (sys/param.h) in that > case? > I couldn't say without double checking the code, but there's a forward limit in http_fopen_wrapper which limits how far the http wrapper will go in following redirects. If that limit is reached the stat would fail or the is_readable would return false. (Just as it would for plainfiles) -Sara