On Mon, 2007-05-07 at 02:17 +0300, ufuk bayburt wrote:
+1 this in core. I maintain IMCE and it uses folder based quotation for users. It scans physical directories to get the file list. With this patch in core one can easily get the files of a user from DB and calculate quota. It would probably be faster than IMCE's current method. (or wouldn't it?)
For a well organized file system directory, what completes this patch and what IMCE currently implements partially and will probably improve, is user(role)-folder associations.
Folders are assigned to user roles, each having its own permission for browsing, uploading, and other operations like deleting, renaming etc. Folder names may contain tokens like %uid and %uname to allow more specialized/personalized directory structure. And a wildcard * can be used for specifying subfolders.
Aye I'd really like to see token support in core, so directory hashing methods for files can be user defined. It is a common problem for large Drupal sites to have too many files in a single directory. Some filesystems just do not handle 10K's of files in directories very well.
an example for an admin role (full access to file directory path): folder1: * permissions: +upload, +browse(+all files, -own files), +delete(+all, -own)
an example for an editor role (a personal folder to upload + browsing access to other editors' folders): folder1: editors/%uname permissions: +upload, +browse(+all, -own), +delete(+all, -own) folder2: editors/* permissions: -upload, +browse(+all, -own), -delete
an example for auth. user role(upload to a shared folder, browse and delete own files) folder1: userfiles permissions: +upload, +browse(-all, +own), +delete(-all, +own)
Note: For limitations/permissions on quantitative values(e.g. user quota), role precedence setting becomes a necessity when a user has multiple roles. Will roles in D6 have weight attribute? Was this discussed anywhere?
This is a really cool concept, I'd like to find a way to have more user control over the permissions, but not something I want to bring home in this patch. I may have to play with IMCE to see the perms in action. I have also been thinking about using the status field and having a FILE_STATUS_HIDDEN that tells other modules to ignore files unless they happen to be responsible for the files.
Then comes the file browser. It will probably have a UI like ftp clients. Users will only be able to see the folders to which they have browsing access.
To list files in a folder faster, it would be better to store filepath as separated into directory name(relative to file directory path) and the filename(as it is now). I think queries like "SELECT ... WHERE dirname='foo'" will be faster than queries like "SELECT ... WHERE filepath LIKE 'foo/'".
Besides that, it may end up where we maintain a folders table. This will be necessary to get subfolders of a folder without a physical folder scan or without a query that includes a regular expression. Think about getting subfolders of the file sytem directory by just using the current files table.
My opinion on this is actually to just use a standard file hash on the server file system, and hide the details of the real system path from the end user, and build hierarchies using meta data to browser files. Most modern music plays provide and interface like this, and I personally find it far more convenient for managing a large number of media files.
Actually this resembles the taxonomy system where taxonomy terms are folders and nodes are files. We should implement a similar but simpler system in order to make the file system browsable by just querying the DB.
To conclude, i liked this patch and thank Darrel for all efforts.
(I would really want to test the patch througly and see the result of porting IMCE to the new system before code freeze. I don't know if i will have time but thanks to Nathan :) i'm not alone anymore in this project.)
Sweet.. .darrel.