Forum OpenACS Development: Re: problems with unique name constraint in cr_items -- file-storage

Collapse
2: Re: problems with unique name constraint in cr_items -- file-storage (response to 1)
Posted by Dave Bauer on 06/07/06 03:10 AM
Stan,

The filename is the URL of the file, so you can only have one in every folder.

What should REALLY happen is, if a file with the same name exists, the system should tell the user, and suggest a unique name, but allow the user to change it.

The confusion comes from people trying to use file storage in two ways, 1) file sharing with extended attributes like "title" 2) replacement for filesystem.

Since the filesystem metaphor conflicts with the title metaphor. If you use file storage like a filesystem, of course creating a new copy of a file with the same name will overwrite the old one. A good application might warn you if this is happening.

So someone (not me) needs to decide how file storage will work. Perhaps adding a parmeter to turn this behavior on or off.

Collapse
3: Re: Re: problems with unique name constraint in cr_items -- file-storage (response to 2)
Posted by Stan Kaufman on 06/07/06 09:29 PM
Ah yes; the filename is the URL. Seems like the desire to avoid URLs like "/storage/one-file?file_id=1234" creates some complications.

In any case, there already is a "BehaveLikeFilesystemP" parameter in the package, but this parameter right now only sets whether in folder-chunk a file's title links to /download/ or to /view/.

I suppose that some behaviors could be added to this parameter on the "file upload" side:

BehaveLikeFilesystemP = 1:
A new uploaded file that has a name conflict with an existing file would generate a new version of the existing file. This doesn't actually overwrite the old one (as you point out it would in a real filesystem) but it effectively does because it becomes the latest/active version of the file.

BehaveLikeFilesystemP = 0:
A new uploaded file that has a name conflict with an existing file would generate a new file, just as if there was no name conflict. Behind the scenes, it would modify the filename by appending an integer (ie if there already is a filename "myduplicate.doc" then the second uploaded filename would be "myduplicate-1.doc".

These upload and download behaviors could be controlled by their own parameters, though, too. That might be clearer and more flexible.

Collapse
4: Re: Re: problems with unique name constraint in cr_items -- file-storage (response to 2)
Posted by Stan Kaufman on 06/08/06 11:23 PM
Here is a patch that checks the BehaveLikeFilesystemP param for a file-storage instance to handle this situation:

  • If BehaveLikeFilesystemP == 1, then file-add.tcl "overwrites" the existing file by adding the new upload as a new version to it and making that new version the live one -- ie just as the current code works.
  • If BehaveLikeFilesystemP == 0, then file-add.tcl alters the filename by appending the new file_id (well, object_id) to provide a guaranteed-unique name, then adding the new upload as a new file in the folder.
  • The patch also provides some I18n instructions explaining what's going on.

This is a pretty simple fix, so unless I hear screams from someone soon, I'll go ahead and commit this to oacs-5-2.