Bug #14157
closedupdating extensions fails because directories are not deleted
0%
Description
trying to update or overwrite an extension that is already installed fails.
It seems like files and directories are expected to be removed prior to getting the new version installed. While all the Files are removed fine, directories however are left in there. So the following check "nothing left in the extension directory?" prior to install fails. Due to this failure the extension doesn't get (re-)installed.
a patch that seems to fix the problem is attached.
In call to '$fileArr =t3lib_div::getAllFilesAndFoldersInPath(array(),$removePath)' it adds the parameters (...,'','1') so directories will be included as well.
the error has been in 3.6-branch for a while I believe, definitly is included in 3.6.1. bug #0000044 seems somehow related
patch works here, not heavily tested.
Warning: rmdir(/var/www/lokal/typo3/beat-ev/typo3conf/ext/rte_pb_htmlarea/htmlarea/): Directory not empty in /var/www/lokal/typo3/typo3_src-3.6.0-cvs/typo3/mod/tools/em/index.php on line 2893
Warning: rmdir(/var/www/lokal/typo3/beat-ev/typo3conf/ext/rte_pb_htmlarea/): Directory not empty in /var/www/lokal/typo3/typo3_src-3.6.0-cvs/typo3/mod/tools/em/index.php on line 2903
....
Extension copied to server
ERROR: Could not remove extension directory "/var/www/lokal/typo3/beat-ev/typo3conf/ext/rte_pb_htmlarea/". Reasons:
Error: "/var/www/lokal/typo3/beat-ev/typo3conf/ext/rte_pb_htmlarea/htmlarea/" could not be removed (are there files left?)
Error: Extension directory "/var/www/lokal/typo3/beat-ev/typo3conf/ext/rte_pb_htmlarea/" could not be removed (are there files or folders left?)
(issue imported from #M79)
Files
Updated by Daniel Poetzinger over 20 years ago
I can confirm the error. Even filesystem rights are 0777 the directory could not be deleted.. (tested for tt_news extension which was installed as GLOBAL extension..)
I also updated other LOCAL extensions, the error did not appear.
Updated by Ingmar Schlecht over 20 years ago
I could not reproduce this.
Please provide more information about your system.
Anyway, your suggested fix doesn't quite seem the right way to do.
This is the code it's all about:
// All files in extension directory:
$fileArr = t3lib_div::getAllFilesAndFoldersInPath(array(),$removePath);
if (is_array($fileArr)) {
// Remove files in dirs:
foreach($fileArr as $removeFile) {
if (!@is_dir($removeFile)) {
if (@is_file($removeFile) && t3lib_div::isFirstPartOfStr($removeFile,$removePath) && strcmp($removeFile,$removePath)) { // ... we are very paranoid, so we check what cannot go wrong: that the file is in fact within the prefix path!
@unlink($removeFile);
clearstatcache();
if (@is_file($removeFile)) {
$errors[] = 'Error: "'.$removeFile.'" could not be deleted!';
}
} else $errors[] = 'Error: "'.$removeFile.'" was either not a file, or it was equal to the removed directory or simply outside the removed directory "'.$removePath.'"!';
}
}
// Remove directories:
$remDirs = $this->extractDirsFromFileList(t3lib_div::removePrefixPathFromList($fileArr,$removePath));
$remDirs = array_reverse($remDirs); // Must delete outer directories first...
foreach($remDirs as $removeRelDir) {
$removeDir = $removePath.$removeRelDir;
if (@is_dir($removeDir)) {
rmdir($removeDir);
clearstatcache();
if (@is_dir($removeDir)) {
$errors[] = 'Error: "'.$removeDir.'" could not be removed (are there files left?)';
}
} else $errors[] = 'Error: "'.$removeDir.'" was not a directory!';
}
It would be helpful if you could investigate why rmdir($removeDir); does not work on your system.
cheers,
Ingmar
Updated by Stephane Schitter over 20 years ago
Hello,
I have the same problems on my install. This occurs even for LOCAL extensions. The type of errors I get are :
Warning: rmdir(/data/www/typo3/websites/dummy-3.6.1/typo3conf/ext/defaultstatic_tmpl/): Directory not empty in /data/www/lib/typo3_src-3.6.1/typo3/mod/tools/em/index.php on line 2903
ERROR: Could not remove extension directory "/data/www/typo3/websites/dummy-3.6.1/typo3conf/ext/defaultstatic_tmpl/". Reasons:
Error: Extension directory "/data/www/typo3/websites/dummy-3.6.1/typo3conf/ext/defaultstatic_tmpl/" could not be removed (are there files or folders left?)
Updated by Stephane Schitter over 20 years ago
I forgot to mention my system details:
Linux-based system
Typo3 3.6.1
My webserver runs as user "apache", and all the typo3 files/directories belong to "apache" as well.
Updated by Peter Niederlag over 20 years ago
@Ingmar(Bugnote 9.6.):
<quote>
It would be helpful if you could investigate why rmdir($removeDir); does not work on your system.
</quote>
Strange you can't reproduce the problem.
rmdir($removeDir) is working very nicely. The problem is that prior to this $fileArr is supposed to be filled with all files and directories. In the call like it is right now, $fileArr only contains filenames, no directories(That is fixed by the patch).
As is $remDirs will just be empty, and when the not empty extension main directory is supposed to be deleted later on "rmdir($removePath)" it wont work, since it is not empty.
t3lib_div::getAllFilesAndFoldersInPath(array(),$removePath) returns an array with only the files.
t3lib_div::getAllFilesAndFoldersInPath(array(),$removePath,'',1) returns an array with the paths and the files.
Please try again(3.6.1):
have some extension (locally? shoudn't make a difference) installed.
try to update this extension(for example manual upload with "overwrite" enabled)
edited on: 16.06.04 12:09
Updated by Wolfgang Klinger over 20 years ago
This happens for any directory below the extension directory that has sub directories, e.g. /my_super_ext/doc/CVS/somefile.bla
(or if you use the smarty extension (templates_c!))
The update will fail because doc/CVS will be deleted but "doc" will not!
[update]
Please download my patch and report success or any failures!
btw 3.7 uses the same code!
edited on: 28.06.04 10:16
Updated by Wolfgang Klinger over 20 years ago
Reminder sent to danp, ingmar, ingmars, juggler, shelob
hiya!
There's a patch online that should fix bug 79 in an accurate way. Please test it.
thx
Wolfgang
Updated by Ingmar Schlecht over 20 years ago
Hi Wolfgang,
your patch basically does two things:
(1.) It changes the following function call from
$fileArr = t3lib_div::getAllFilesAndFoldersInPath(array(),$removePath);
to
$fileArr = t3lib_div::getAllFilesAndFoldersInPath(array(),$removePath, '', 1);
(2.) It provides a new implementation of the function extractDirsFromFileList().
However, in my installation it was only required to change (1.) and leave (2.) untouched.
What was exactly the purpose of (2.)?
cheers,
Ingmar
Updated by Peter Niederlag over 20 years ago
I have provided and been using patch (1.) for a while now and never found any problems.
http://bugs.typo3.org/file_download.php?file_id=22&type=bug should be enough to solve this bug.
Peter
Updated by Wolfgang Klinger over 20 years ago
It returns all directories, see the following example:
e.g.
my_ext/dir1/dir2/dir3
OLD:
extractDirsFromFileList will return
my_ext/dir1/dir2/dir3
NEW:
extractDirsFromFileList will return
my_ext/dir1/dir2/dir3
my_ext/dir1/dir2
my_ext/dir1
And that's the only reason for the error message, because Typo3 deletes my_ext/dir1/dir2/dir3 sucessfully but the other two remain untouched!
And the change to $fileArr = t3lib_div::getAllFilesAndFoldersInPath(array(),$removePath, '', 1); is basically unnecessary as long as there are files in the directories (in that case the directories are returned too)! Though I haven't looked at that carefully enough as it works well with this changes anyway...
Updated by Ingmar Schlecht over 20 years ago
OK, but that is not necessary if the line looks like:
$fileArr = t3lib_div::getAllFilesAndFoldersInPath(array(),$removePath, '', 1);
Because the function getAllFilesAndFoldersInPath() would already return something like this:
my_ext/dir1/dir2/dir3
my_ext/dir1/dir2
my_ext/dir1
So it's not necessary anymore that the function extractDirsFromFileList() does this as well.
Anyway, the fix is currently in the process of entering the 3.6.2 code so we don't have to worry about it anymore.
Resolved.
Updated by Ingmar Schlecht over 20 years ago
this is now fixed in CVS so it'll be fixed in 3.6.2.