Project

General

Profile

Actions

Bug #14157

closed

updating extensions fails because directories are not deleted

Added by Peter Niederlag over 20 years ago. Updated over 18 years ago.

Status:
Closed
Priority:
Should have
Category:
Backend API
Target version:
-
Start date:
2004-05-12
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
3.6.1
PHP Version:
Tags:
Complexity:
Is Regression:
Sprint Focus:

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

0000079-patch_em_index.php (594 Bytes) 0000079-patch_em_index.php Administrator Admin, 2004-05-12 09:23
0000079-patch_em_index.txt (594 Bytes) 0000079-patch_em_index.txt Administrator Admin, 2004-05-12 09:28
0000079-patch_t3_361_bug_79.diff (997 Bytes) 0000079-patch_t3_361_bug_79.diff Administrator Admin, 2004-06-27 18:39
Actions #1

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.

Actions #2

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

Actions #3

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

Actions #4

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.

Actions #5

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

Actions #6

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

Actions #7

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

Actions #8

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

Actions #9

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

Actions #10

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

Actions #11

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.

Actions #12

Updated by Ingmar Schlecht over 20 years ago

this is now fixed in CVS so it'll be fixed in 3.6.2.

Actions

Also available in: Atom PDF