passing in a full destination path to file_move / copy could cause the file system to be abused by trying to place files outside of the file system directory.
if the paths stored in the {file} table are stored as being relative to the file_directory_path(), (http://drupal.org/node/366464) this will cause problems. so imo, the $destination arg should be relative to the files directory, and not relative to the drupal installation.
should file_unmanaged_move/copy be left as relative dirs to the drupal installation. as these don't touch the db, i think the above restriction doesn't apply?
opinions?
Comments
Comment #1
George2 commentedi think they should because by limiting the output of these functions to one place means that all files related to the drupal installation will be contained in one place.
this would cause a problem however if these functions are used to move files to the temp directory, so maybe the function should check if the destination is the temp dir, and if not, move the file relative to the file_dir_path?
Comment #2
j.somers commentedI disagree.
In one of the custom modules of the website I am currently working on I use these functions to place certain files outside of the web root directory to a "protected" directory which cannot be access from the website itself. It would be silly to create my own implementations of these functions to do that.
Comment #3
drewish commentedI think what we really need to do is to rework #166759: Public/Private File Handling and have two "files" directories: files-public, files-private in addition to a temporary directory. Once that's the case then depending on the $file->status file_copy() would only allow the file into one of those three directories based on the $file->status.
If j.somers needs the file to be in another destination then he could use file_unmanaged_copy() which would not enforce the limitation.
Comment #4
aaron commentedI'm not sure this is even an issue now, as we're using streams for file storage. Can we close this issue?