Opened 9 years ago
Closed 8 years ago
#34067 closed defect (bug) (duplicate)
Filesystem API should not delete contents of symlink'd folders
Reported by: | khag7 | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 4.3.1 |
Component: | Filesystem API | Keywords: | |
Focuses: | Cc: |
Description
In almost any filesystem, deleting a symbolic link or junction point (NTFS) doesn't delete the original, it just removes the link. The Filesystem API delete function is used when deleting a plugin and it recursively empty the folder by deletion before attempting to delete the parent folder. The expected behavior in any other file system would be that the parent folder symbolic link is just removed, but the original files do not get deleted.
You may think this does not apply to wordpress, but in some cases, plugins are installed via symlinking(linux) or junctioning(windows) a directory from another location. In these instances, deleting the files isn't appropriate, simply removing the symlink or junction is needed.
I propose that before doing a recursive delete, the parent folder should be attempted for removal using rmdir() and unlink(). rmdir is capable of removing junction'd folders (NTFS file system) and unlink can remove symbolic links. After attempting to remove the directory through those two methods, if both fail then go ahead and do what we already do which is to do a recursive file deletion and then remove the directory.
I'm filing this under the Filesystem API since this could presumably affect any instance of doing a delete, not just plugins.
+1. I've been bitten by this before when deleting a symlinked plugin, and it was definitely not expected behavior.