[TYPO3-core] RFC: Bug #9307: Remove an obsolete check for disable_exec_function in filelist

[Steffen Kamper]

Hi,

Christian Kuhn schrieb:
> Hi,
> 
> Steffen Kamper wrote:
>> i don't think we need such in 4_2 as it's only cleanup.
> 
> The reporter stumbled upon this in his safe_mode environment, and 
> dont_use_exec_commands will also be set to true on Win. So its a bit 
> more than a cleanup, imho a commit to 4.2 is justified.
>

i see, so ok for me.
To make it short - my +1 for this patch


> 
>> I looked for further usage of this var. It's also used for
>> * copying a folder
>> * func_unzip
>>
>> for copy i think there is also no exec method, but for unzip there is.
> 
> Yep, I checked that, too.
> 
> Line 528:
> $cmd = 'cp -R "'.$theFile.'" "'.$theDestFile.'"';
> exec($cmd);
> 
> So exec is both used for unzip and recursive copy and the checks are ok.
> 

hm - why? :-) could be done with php also.
> 
>> So my question: is there an alternative for unzip with php? i found 
>> the zip_open, ZipArchive::extractTo etc, but i didn't looked further 
>> for implementation
> 
> There is also $this->PHPFileFunctions, if true php internal functions 
> (rename(), copy(), ...)  will be used, exec() if false. I wonder why 
> there is a fallback to exec() anyway?
> 
> Maybe we could clean this up in another rfc and implement a php internal 
> unzip? Who would want to disable copy() or rename(), but enable exec() 
> in his php setup?
> 
> My suggestion is to get this obvious bugfix in, then we discuss if a 
> general cleanup makes sense.
> 
> 

as the patch here is absolute nobrainer i will commit it in a few hours.
So no problem to discuss the general cleanuo to prepare a new RFC. See 
my other post where i suggest em_unzip for the zip, lets do 
copyRecursive in a native php way, what do you think?

vg Steffen