I installed WebFM 2.1 in Drupal 5.5 but then later had to change my directory structure to accommodate additional sites.

I went from: /drupal/files/ to /drupal/files/site1 and: /drupal/files/site2

I created the /files directory as the Drupal file system path but allowed WebFM to create the site subdirectories. Each site has it's own /modules directory to keep everything separate. The problem is that it wouldn't let me do this change after uninstalling and reinstalling the module (ver 2.2 this time) - it wanted to go back to the old structure - even though the db tables were dropped in the uninstall it somehow remembered the old structure. There's something about the menu cache in the readme but I could make no sense of that.

I uninstalled the module but first had to disable it. The uninstall directions say:

Drupal 5.x

1. Disable the module on the /admin/build/modules page
2. Click on the uninstall tab and select the module for removal. This will automatically drop the webfm_file and webfm_attach tables as well as all configuration variables.

NOTE: This action will permanently discard all attachment and metadata information and cannot be undone. Execute the first step only if you wish to restore WebFM later without loss of data.

This doesn't make sense since you are not given the option of skipping the first step.

How do I start over?
------------------------------
Other questions:

In the install directions it says: Multi directory root paths must already exist inside the 'File System' directory. Is this referring to multi-site directories or what?

Files permissions are controlled by role and file UID. Does this mean only the Drupal user who uploaded this file can retrieve it or does it mean I can create subdirectories only visible/accessible per user? I suspect the former, in which case just exactly what are the restrictions? I presume everyone can see the files but only the owner can move, delete, view, or download them.

Tnx, Jeff

Comments

robmilne’s picture

it wanted to go back to the old structure
I have never seen this and find it hard to believe. There is nothing inherent to the module itself that would cause this behaviour. Perhaps some form of cache is interfering but I cannot say with what little info I have. I admit that I haven't uninstalled/reinstalled webfm very often but you could try running cron.php and update.php after uninstall and before reinstall.

The module will automatically create directories (assuming they don't already exist) if located directly within the 'File System' directory (ie: files/webfm), however if you set the root to be dir0/dir1/webfm then the dir0/dir1 path must already exist (ie: files/dir0/dir1). The module will not recursively create the directories between 'files' and 'webfm'.

Permissions are fairly crude in webfm (the module was originally designed as an admin tool with only admin level privileges). The 2.x versions implement user privileges via role/path and UID. The UID isn't used as extensively as it should due to my supposed retirement from this project (I jumped back in for 2.2 because download security was non-existent and the new maintainer isn't working on the module) but it does prevent non-admins from executing move/rename/delete/metadata-edit ops on files they don't own. The obvious enhancement that would make the UID more useful would be the addition of a flag column that sets file privacy in the webfm_file table. As it stands, all webfm users of a specific role can view/download every file in the root directory for that role (assuming the file is in the db - files placed in the directory directly via shell are not viewable by non-admins until inserted into the webfm_file table by an admin user). Other missing pieces would be a directory creation right for non-admins, an admin by role category and a way to alter the file UID other than by direct db manipulation. I won't be implementing any of these features unless 2008 has 13 months.

robmilne’s picture

Status: Active » Fixed

Ver 2.6 fixes uninstall bug

Anonymous’s picture

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.