• (nodebb)

    I like the underscore after "recursive", but no underscore after "read".

  • Darren (unregistered)

    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?

  • Jaloopa (unregistered) in reply to Mr. TA

    I like the underscore after "recursive", but no underscore after "read".

    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

  • FTB (unregistered)

    Not the WTF but I think it fails.

    It tries to rmdir() before deleting the contents of the folder.

  • (nodebb)

    Someone must have executed "recursive_hold_comment_for_moderation"

  • (nodebb) in reply to Mr. TA

    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.

  • Sauron (unregistered)

    We should update the meaning of the C.R.U.D acronym.

    Now, C.R.U.D = "Create, Read, Update, Read".

  • (author) in reply to FTB

    It might fail- or it might be looking at an already empty directory at the time.

  • (nodebb) in reply to miquelfire

    Yes, readdir is 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 -rf would be a much simpler way to do this. Then again, I wouldn't trust this programmer to get the quoting and escaping right (PHP has escapeshellarg() for this purpose, but would they use it?).

  • (nodebb) in reply to Darren

    The names rmdir and unlink merely mirror the names of the equivalent Unix system calls. No need to blame PHP for this one.

  • Fordom Greeman (unregistered)

    When I see the $ sigil in front of vars my brain automatically switches to the "expect the unexpected" mode

  • (nodebb)

    It's certainly not as bad ( or as good ) as the infamous %% sudo rm -rf /
    command

  • Jonathan (unregistered) in reply to Darren

    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.

  • Sou Eu (unregistered) in reply to miquelfire

    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:

    1. 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.

    2. Not checking to see if the passed in $path exists and is a directory.

    3. Calling rmdir before making the recursive call.

    4. General lack of error handling.

  • Stuart (unregistered) in reply to Darren

    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.)

  • richarson (unregistered) in reply to Sauron

    You mean "Create, Read, Update, reaD", right?

  • commenter (unregistered) in reply to jeremypnet

    and 'unlink' would make sense if you knew the first thing about filesystems or computers in general

  • (nodebb)

    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.

  • Anne on a Mouse (unregistered) in reply to Stuart

    Actually, Windows supports hard links, too, it just makes it hard to create them (as does Mac OS X — command line only, and you have to use sudo for it), and ISTR that if you use them on Windows they can cause certain non-fatal-but-irritating malfunctions. (But it’s been years since I read about it so I could be misremembering and/or that caveat could be out of date.)

Leave a comment on “Reading is a Safe Operation”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article