This is probably the weirdest thing that has ever happened to me since the first time I touched a computer.

I'm having issues with the textimage module lately... so a couple days ago I decided to deactivate and uninstall the module off the database with the drupal uninstall feature. As soon as I hit the 'ok' button HD drive started to work like mad and the page was five minutes on 'loading' until I stopped the process. By the time I did that, my apache server had stopped working. After a short period of research I found out it wasn't a crash or anything typical: its windows 'Program Files' 'apache' forder was gone, and so where 7.15GB of many other program files ('Adobe', 'Awstats',...). I did not relate both things at first,- I thought it was a virus and migrated to linux in a burst of anti-windows anger. Ok, once in linux (Mandriva 2007), and after migrating my whole site (thank god data was intact), I tried the uninstall move again. Guess what happened. All the files with 777 permissions were gone, although thanks to the linux's permissions architecture they only summed up approx. 100MB.

WTH is wrong and why have I not seen anybody with a related issue if this seems environment and OS unrelated?

Thx,
Phil

Comments

filiptc’s picture

filiptc commented
Status: Postponed (maintainer needs more info) » Active

Although 'needs more info' (as set initially) would be more appropriate, I'm setting the status to 'active' to draw attention.

saintchuck’s picture

saintchuck commented

I too lost all files (except .htaccess) in site root after attempting uninstall of textimage. Not sure that I can add anything other than it is a problem. Linux production server, Drupal 5.0 clean install, all files gone.

heine’s picture

heine commented

textimage.install:29

function textimage_uninstall() {
  _textimage_recursive_delete(realpath(file_directory_path() .'/textimage'));

textimage.module:981

function _textimage_recursive_delete($path) {
  $listing = $path . "/*";
  foreach(glob($listing) as $file) {
    if(is_file($file) === true) {
      @unlink($file);
    }
    elseif(is_dir($file) === true) {
      _textimage_recursive_delete($file);
      @rmdir($file);
    }
  }
  @rmdir($path);
}

Whenever "file_directory_path() .'/textimage'" doesn't exist, realpath returns FALSE, and _textimage_recursive_delete starts to work on /*.

Consider removing this feature.

@OP: NTFS allows very fine grained permission control on files and directories.

luti’s picture

luti commented

I agree such a source of potential disaster should not find a place in any part of drupal or modules belonging to it!

Probably it shouldn't be too hard to check a delete path first - if it actually is what it should be (and, in particular not empty, or anywhere above the module directory). Or, simply not delete anything by uninstall - we also have to manually put the files in place. Uninstalling still doesn't mean that I will not turn the module back on after some minutes, at the end...

I would prefer modules to let you choose weather to keep the settings (in case I suspect some module is causing certain problem, and want to turn it off just temporary) or to erase all of them (when it has to be permanently removed, or reinstalled as fresh installation).

Am I the only one having such thoughts?

filiptc’s picture

filiptc commented

@Heine

Whenever "file_directory_path() .'/textimage'" doesn't exist, realpath returns FALSE, and _textimage_recursive_delete starts to work on /*.

I don't know...: the textimage dir was present when I did hit uninstall, so consider the source of the issue being somewhere else.

@LUTI

I would prefer modules to let you choose weather to keep the settings (in case I suspect some module is causing certain problem, and want to turn it off just temporary) or to erase all of them (when it has to be permanently removed, or reinstalled as fresh installation).

Am I the only one having such thoughts?

I think the uninstall feature should uninstall everything in the database that belongs strictly to that module. In many cases (like initially mine) its purpose is trying a clean install of the module to solve any problem the module might have. If you just wanted to erase the settings you could do so manually (I think you can find them in the 'variables' table). I believe making the uninstall feature gradual is only possible through patches to the core modules and should therefore be feature requested in the drupal project.
But I definitely agree on the "such a source of potential disaster should not find a place in any part of drupal or modules belonging to it" thing.

Phil

wundo’s picture

wundo commented

See #116307 .

wundo’s picture

wundo commented
Version: 5.x-2.x-dev » 5.x-1.1
Status: Active » Fixed
Anonymous’s picture

(not verified) commented
Status: Fixed » Closed (fixed)
jds013’s picture

jds013 commented

This just happened to me... I clicked uninstall for the File module (current version), and it deleted every non-read-only file on the drive. I have an extra week's work to do now to try to restore multiple applications... Unbelievable.

I'll try to find time to report more data when I get a chance.

deciphered’s picture

deciphered
Primary language English
Location Ballarat, Victoria, Australia
commented

@jsd013,

Firstly, this issue was closed over 2 years ago, so you're amazingly lucky that someone would even bother tacking the time to respond.
Secondly, this issue is for the Textimage module, not the File module. I would suggest you create an issue in the File module issue queue.

Cheers,
Deciphered.