Bitcache deletes files from system (was: Eiether Views 2 or File Framework just deleted every file in my public folder)
bjraines - February 6, 2009 - 23:08
| Project: | Bitcache |
| Version: | 6.x-1.0-beta2 |
| Component: | Miscellaneous |
| Category: | bug report |
| Priority: | critical |
| Assigned: | miglius |
| Status: | active |
Jump to:
Description
Following up on a previous support ticket.
while disabling the views module I decided to go ahead and disable to File Manager to try a reinstall with the Bitcache and other module, I forget its name.
I then click the Uninstall tab to try and be thorough, the system stalled
Then when I went back to the site, it was gone.
but not only was this drupal site gone, every file of every site in every subfolder was gone. Zencarts, Joomlas, Wps, and all Drupal sites.
I am not complaining just asking you to check in to it.
I feel strongly it was not Views alone as I have uninstalled it many many times.
#1
I doubt that FileFramework could have deleted the files on your system. FileFramework does not work with the files directly, but via the Bitcache module. The Fileframework could not delete files it is not aware of.
#2
This has happened to me, as well. Everything that Apache has permissions to write gets deleted.
#3
ditto here too.
this is my favorite bug of all time.
just use the devel module to reinstall the file module and watch what happens.
amazing!
#4
This is really true. I am raising priority. I didn't have time to investigate this but it seems that because you uninstall file module, bitcache_delete_repository is run and bitcache deletes a file repository without a proper path.
#5
file framework calls bitcache_delete_repository('file'). this calls File::destroy($options), where $options is second argument of the delete_repository. Therefore there are NO options and there is no path. No File::$path variable, therefore rmdir_rf is called and it deletes "/*".
voila...
#6
The only option which is used in the bitcache file adapter in the destroy() method is $options['contents']. The Bitcache_FileRepository::$path is initiated in the bitcache_delete_repository() function's bitcache_get_repository($name) call and does not take any options.
It looks like this might be a bitcache bug (it should not delete files if $path is not set) or a FileFramework migration issue (when a location option was introduced, bitcache_repositories table might need an update).
#7
When the files were deleted, were you using a new installation of the bitcache/fileframework, or updated earlier versions?
#8
completely new installation
#9
To avoid this problem please upgrade to the dev version of the bitcache. This issue is already solved and should not occur in the dev version. Nevertheless, I have added a safeguard condition before calling Bitcache_FileRepository::rmdir_rf() to check if the path is not empty.
Alternatively, if you're using a bitcache beta2 version and want to uninstall the bitcache and fileframework, please, uninstall the fileframework first and only then proceed to uninstalling bitcache.
This issue occurs if the bitcache and fileframework are unistalled at the same time. The drupal uninstalls the disabled modules alphabetically, which means that bitcache is uninstalled first and bitcache_repositories table is removed before a fileframework unistall takes place. Fileframework, on the other hand, on uninstall tries to load it's repository info and fails since it is already deleted in the bitcache uninstall. Bitcache beta2 version defaults to the "file" adapter if no repository info is available which results in the instantiation of the class Bitcache_FileRepository and invocation of the method rmdir_rf() without a $path defined. Dev version of the bitcache does not defaults to the "file" repository if no repository data is available.
@Arto, should you consider a cut of a new release to prevent people who are not aware of the issue from losing the files?