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

[Darrel O'Pry]

On Sat, 2007-05-05 at 06:28 +0300, Cog Rusty wrote:
> I wonder what the user-file association would mean for a site which
> hires/fires editors and still owns/reuses their files. Or in a site
> like drupal.org with patches as attached files?

files won't be deleted if users are deleted. for ownership we can assume
uid 1 safely if user.uid doesn't exist.

> I understand that the orphaned user-files would pile up in a default
> user account, but if that is very likely to happen for a lot of files,
> then user ownership of files would seem accidental.

huh? pile up in a user account? accidental?
user_access always returns true when uid=1... that isn't accidental.

This patch cares very little for where files pile up when a user is
deleted.  Right now we don't really care what happens to files if their
node gets deleted and they don't, but we also don't have any safe way of
sharing files between nodes. 


> Perhaps files should be able to stand on their own, with options to
> associate then with nodes or users?

Then who can update, delete, and alter files? How do you control access
to files? Drupal's permission system is user based, hence user_access. 

I've thought about this issue a lot. I've explored it and alternatives
quite a bit over the last year. It's the easiest way I've found to
implement files in Drupal without depending on nodes. It should be a
fairly familiar model, most filesystem systems implement user ownership
of files and grant the system super user an all access pass. The patch
for changing default file relationships from nodes to users solves many
issues without introducing excessive permissions related issues. 

It's a relatively simple change that doesn't introduce any new tables,
and only make a minor change to our existing data model.

The real point of this patch is remove all the hackage associated with
file previews... Have you ever looked at the code that handles
displaying file previews? Basically today, we have to save the file to
the session, create a fake menu entry for the file at its final
destination, and serve the file preview through drupal.  It's kind of a
pita, resource hog, and in makes file previews dependent on clean urls.

Search through the issue queue for file preview related bug reports. 

Look at the crazy code that does file path replacement for node bodies
during previews.  Look at inline and how it manages to work with
previews...

It was the most difficult part for me to figure out working with
drupal's files.  I want to eliminate that pain from every other
developer's life. 

As an aside this patch also centralizes validation handling from
upload.module to file.inc, so we do gains centralized quota's and file
extension validation as boon.

Resolving the hanging temp file issues for uploads for this patch also
resolves the long standing issues with garbage collection in drupal 4.7
and 5.

The patch has been updated with feedback from unconed(steven wittens)
and quicksketch(nate huang). I was able to resolve several issues with
the patch. It's miles from where it was yesterday, and awaiting a fresh
thrashing and some kind pgsql maven to write a pgsql update path.

http://drupal.org/node/115267

.darrel.