[development] files owned by uid, patch review request.

[Darrel O'Pry]

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.