php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #51763 SplFileInfo::getType()
Submitted: 2010-05-07 03:36 UTC Modified: 2010-09-06 16:58 UTC
Votes:1
Avg. Score:3.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: v-sumada at microsoft dot com Assigned: pajoye (profile)
Status: Closed Package: SPL related
PHP Version: 5.3.2 OS: All windows OS
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: v-sumada at microsoft dot com
New email:
PHP Version: OS:

 

 [2010-05-07 03:36 UTC] v-sumada at microsoft dot com
Description:
------------
The SplFileInfo::getType() For Symbolic link returns "dir" which in turn should return "link" .This happens to be in 5.3.2 and occurs on all windows OS.

It Correctly  returns the type of  file referenced which is for Dir  and File . 


<?php
$symlinkdir = "/path/to/symlink"; //Symbolic link
$syminfo = new SplFileInfo($symlinkdir);
var_dump($syminfo->getType());
?>

Expected result :string(4)"Link"
Actual result : string(3) "dir" 

Test script:
---------------
<?php
$symlinkdir = "/path/to/symlink"; //Symbolic link
$syminfo = new SplFileInfo($symlinkdir);
var_dump($syminfo->getType());
?>

Expected result:
----------------
string(4)"Link"



Actual result:
--------------
string(3) "dir" 

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2010-05-08 05:05 UTC] cataphract@php.net
This is unrelated to Spl. is_link/etc. are all also windows symbolic link agnostic. The problem here is that this information is conveyed in the stat structure. Strictly speaking, the return of getType is not completely incorrect -- the file type _S_IFREG and symbolic links are in fact files or (empty) directories with reparse point data. Maybe the best thing to do would be to change the stat function returned on windows so that the file type is replaced with _S_IFLNK when the directory is a junction/symlink or the file is a symlink.
 [2010-05-08 05:07 UTC] cataphract@php.net
The comment should read "information is NOT conveyed in the stat structure".
 [2010-05-08 07:42 UTC] johannes@php.net
-Status: Open +Status: Assigned -Assigned To: +Assigned To: pajoye
 [2010-05-19 07:14 UTC] kalle@php.net
As noted, the issue here is within php_stat() and its way to detect links. php_stat() uses the S_ISLNK() macro to check if the stat.st_mode have the bits for a like, as on Unix.

What we probably need to do is to use GetFileAttributes() and check for: FILE_ATTRIBUTE_REPARSE_POINT.

After some further debugging it seems that the php_stream_stat_path_ex() function makes the fail. I only tried with symbolic-linked directories, but I would assume the cause would be the same on files. Which brings us to the point where the bug must be located within the url_stat function within the fopen() wrapper.
 [2010-05-19 10:48 UTC] pajoye@php.net
The problem is the same than ::isLink. It calls realpath which will resolve the link before calling the stat function.
 [2010-09-06 16:58 UTC] pajoye@php.net
-Status: Assigned +Status: Closed
 [2010-09-06 16:58 UTC] pajoye@php.net
This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.


 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Mar 29 13:01:29 2024 UTC