- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
I like the underscore after "recursive", but no underscore after "read".
Admin
Not being familiar with PHP, unlink seems an odd choice for the name of a file deletion command - especially as the command for removing a directory is called rmdir. Was rmfile too descriptive to use?
Admin
That's because it's not read dir, it's re-addir, a typo for re-adder. Because you have to re add everything that gets deleted by the method. It's quite clear really
Admin
Not the WTF but I think it fails.
It tries to rmdir() before deleting the contents of the folder.
Admin
Someone must have executed "recursive_hold_comment_for_moderation"
Admin
Ah yes, the wild days of PHP, where 90% of the function didn't follow a standard naming convention because it just blindly exposed the API of the library it was using. So extension A would use function_name(), extension B would use functionName(), and so on. I think all f_functionName() would just drop the f_ part.
Would not surprise me if readdir() was something built into an OS PHP was made for at first. I don't know what the convention was for functions not exposing some other library. At some point, they started using a standard convention, so everything added after that point is following that now. User written code could ignore that and use something else, like how this function did it.
Admin
We should update the meaning of the C.R.U.D acronym.
Now, C.R.U.D = "Create, Read, Update, Read".
Admin
It might fail- or it might be looking at an already empty directory at the time.
Admin
Yes,
readdiris a standard Unix system call, it's been around since long before PHP. Why wouldn't they just copy the name, since it's used almost identically. And if the user's function were actually just reading, its name would be fine.While we should generally avoid shelling out when there are built-in functions that perform the same task, there's no "delete directory hierarchy" function in PHP. Calling
rm -rfwould be a much simpler way to do this. Then again, I wouldn't trust this programmer to get the quoting and escaping right (PHP hasescapeshellarg()for this purpose, but would they use it?).Admin
The names
rmdirandunlinkmerely mirror the names of the equivalent Unix system calls. No need to blame PHP for this one.Admin
When I see the $ sigil in front of vars my brain automatically switches to the "expect the unexpected" mode
Admin
It's certainly not as bad ( or as good ) as the infamous %% sudo rm -rf /
command
Admin
It's actually the Unix file system, not PHP, that you're unfamiliar with. :-)
And the reason for the name is that
unlink()doesn't necessarily delete the file. Search for "file with multiple hard links unix" if you want to learn more.Admin
Many of the builtin php functions just copied the names from the standard c library (opendir, readdir, rmdir, unlink, closedir). PHP has experienced growing pains with the hodgepodge naming convention for builtin functions.
I see the following main WTFs:
Misleading method name. I would expect recursive_readdir to return a recursive list of files and sub-directories. Additionally, that name should either be recursive_read_dir or recursiveReadDir for consistency.
Not checking to see if the passed in $path exists and is a directory.
Calling rmdir before making the recursive call.
General lack of error handling.
Admin
In the Unix world, it is possible for a file to have multiple paths. The actual data in a file is linked to via a structure called an inode. This structure holds the ownership, access permissions, and other such data as well as the location of the data on disk.
A directory holds a listing of filenames, and the inodes that those filenames refer to. If you want to create a second directory entry for the file, without making a duplicate copy, you can create something called a "hard link": a directory entry that points to the exact same inode as another directory entry.
Each inode contains a reference count: "this is how many times directories point at me." Hence, unlink: removing a directory entry and reducing the reference count in the inode. When that reference count reaches zero, the file has been removed from all locations, and its disk space can be freed up (ie: the file finally gets deleted.)
So, in Unix parlance, "unlink" is actually the correct term: whether or not a file is deleted from disk depends on whether the unlink system call removes the last reference to the file.
It is generally the case that you can't create a hard link to a directory; doing so could introduce a recursive loop to a higher level, making it impossible to remove that segment of the tree (because you can't remove a directory unless it's empty.) For example, creating a subdirectory that is a hard link to its parent directory. Apple broke that rule when it created Time Machine, but that's the only case I know, and they were very careful to limit how it could be used.
(Note that this comment is a very loose and general comment about Unix filesystems; there's a lot of detail I'm deliberately not going into in order to explain the particular point at hand.)
Admin
You mean "Create, Read, Update, reaD", right?
Admin
and 'unlink' would make sense if you knew the first thing about filesystems or computers in general
Admin
To the people complaining that the name is "inconsistent": Note that this function calls another, standard function called "readdir". It makes complete sense to name a function that calls this existing standard function recursively on subdirectories (I know that's not what this function does; but that's not my point here) "recursive_readdir". Naming it something else would obscure the fact that it's calling "readdir". I supposed "recursivereaddir" would be somewhat acceptable, but that's even harder to read.
You should probably be complaining that "readdir" should have an underscore... But that's an old POSIX function that's been around for decades. Back then you couldn't rely on the compiler supporting more than 6 "significant" characters in a function name, so they had to be kept short. On such a compiler, the symbol name "readdi" is definitely better than "read_d"; you just know someone would have come along with "read_data" or something and cause a conflict.