File Archive
- Geoff Bowers
- Former user (Deleted)
File Management
FarCry follows specific rules with respect to how physical files are created, updated, deleted and archived.
Content Migration Issues
FarCry 4.0 does not store media content in a tree based hierarchy (unlike FarCry 2.x). Media content is classified using categories or by direct association with a specific content item.
Document Handling
FarCry creates a database record or file content item that holds all the extraneous metadata associated with a file, such as categorisation, document date, publish date and so on. In addition, the content item is attached to a physical file that is stored on the application file system.
When a file content item is created, the system ensures that any attached document has a unique name on the server. Attempting to upload a document of the same name as something already on the server will result in the uploaded file being renamed to ensure that it is a unique file reference.
When a file content item is updated, the system allows you to upload a new file to update the current record. Regardless of the uploaded documents file name, the system will rename the associated document to have exactly the same name as the previously uploaded file. In effect, it replaces the old file on the system.
If the file being used to update an existing file has a different extension, it is assumed to have a different MIME type, and the system will reject the newly uploaded file reporting a conflict. For example, attempting to upload a PDF over the top of a Word document and retaining the exact filename is going to be fraught with danger.
Archiving File Content
When an associated document is updated or the file content item is deleted, the physical file that is no longer required is moved to an archive section of the project.
The archive location is configurable but by default is:
./projectname/mediaArchive/typename/propertyname/objectid-epochdatetime-filename.ext
- projectname: the name of the current application
- typename: the specific content type in question, eg. dmFile
- propertyname: the specific property name holding the file path information
- objectid: the UUID of the file content item
- epochtime: the number of seconds elapsed since midnight UTC of January 1, 1970
- filename: the filename of the document
Typically typename/propertyname would be defined as part of the formtool metadata for file; ftDestination. A defacto standard for content types with a single file property is to simply use the typename value. For example, core content type dmfile uses ./mediaArchive/typename/*
Archived files are not readily retrievable or restorable by contributors in the system. The archive is generated primarily for archival and audit purposes.
Note: The archive feature assumes that the solution has been configured to archive media content. Archiving media assets is a server configurable option and is commonly deactivated.
Versioning & Approval
Files have status only, there is no inherent versioning of files. Setting a file to a status of draft will prevent others from using it in the content management system and prevent users from downloading it (assuming secure files have been configured).
File content items are not versioned as the attached file is considered to be complete. That is, it was already worked on elsewhere and when its uploaded the document has been pre-approved.
Versioning files, whilst maintaining the same filename and in-line linkages would be a very different approach to the current methodology and would essentially require a completely custom and separate file content type.