Forum OpenACS Development: fix for file storage

Collapse
Posted by Ben Adida on
file storage currently does something a bit weird which has caused errors in the past, and still doesn't seem quite right: when uploading a file, the system :

- tries to look up the mimetype using the cr_mime_types

- if it fails, tries to guess the mimetype using ns_guesstype (which basically looks at the AOLserver config file).

- if it finds a mime type, it inserts it into cr_mime_types

It doesn't seem right for code to randomly update cr_mime_types. Also, the only time new mime types might show up from ns_guesstype is if new ones have been added to AOLserver.

I've implemented and tested a local fix that changes acs-content-repository and file-storage:

- on boot time, acs-content-repository scans AOLserver declared mime types and inserts them into cr_mime_types if necessary

- file storage simply looks things up in cr_mime_types, never trying to insert new types along the way.

If people think this is the right way to go, I'll commit my fix (to HEAD not the 4.6 branch, seems like too big a change for the 4.6 branch).

Collapse
2: Re: fix for file storage (response to 1)
Posted by Jeff Davis on
The problem is cr_mime_types is not an extension to mime_type map. It is a mime type listing that happens to include an extension I think the right answer is a cr_extension_mime_type_map table for the mapping (which could be populated at startup I guess) into which new extension - mime type mappings are inserted.

You do want to map multiple extensions into one mime type and duplicate mime types in cr_mime_types is a pretty ugly thing from the standpoint of pulling content out (I think there are a number of places it is assumed mime type is unique in that table).

Collapse
3: Re: fix for file storage (response to 1)
Posted by Ben Adida on
Jeff: you're absolutely right. A table of mime types and a table of mappings seems like the right thing. That does involve a data model change with potentially large impact (depending on the usage of the cr_mime_types table).

I'll put together a prototype of this at some point. Won't commit until I have the full fix. (and I want to focus on forums/notifications first, too).

Collapse
4: Re: fix for file storage (response to 3)
Posted by Tilmann Singer on
Could someone in the meantime please fix the current erroneous behaviour of file-storage, e.g. by not updating cr_mime_types at all?

(I offer to do it if nobody else wants to)

Collapse
5: Re: fix for file storage (response to 1)
Posted by Ben Adida on
Tilmann - I guess I can actually commit my fix as is since it doesn't change data model. I will do that now, to the OpenACS HEAD. Still, we should go Jeff's route long term.
Collapse
6: Re: fix for file storage (response to 5)
Posted by Tilmann Singer on
That's great, thanks.

Do you think it can be merged in oacs-4-6 as well? After all we want to get rid of all the bugs in there before releasing it ...

Collapse
7: Re: fix for file storage (response to 1)
Posted by Ben Adida on
I can merge into 4.6 if this seems like the right thing to do: any objections from anyone?