topic Re: Versioning for non-supported file types in Alfresco Archive

Versioning for non-supported file types

boden — Tue, 13 Jan 2009 16:34:12 GMT

I have some files in Alfresco that are not of a supported type. Specifically, they are product label templates created in Seagull Bartender software (.btw). Alfresco sees them as type "Octet Stream".I would like Alfresco to maintain version history for these files. However, when I enable versioni

Re: Versioning for non-supported file types

loftux — Tue, 13 Jan 2009 17:53:46 GMT

I think this is because the editing application you are using is actually not opening the file and then saves the changes back using a filestream to that file. It opens the file, and then save the changes to a copy, delete the original and then renames to original filename. For Alfresco, this is a new file just as if you would have done this manually.

Re: Versioning for non-supported file types

boden — Tue, 13 Jan 2009 18:36:27 GMT

Yep, you're right. I edited the file in a text editor and the versioning worked.

Is there a workaround or better practice for supporting applications that work this way?

Re: Versioning for non-supported file types

boden — Wed, 14 Jan 2009 19:16:35 GMT

How about disabling CIFS on a space to force users to use the web interface for check-in / out?

Re: Versioning for non-supported file types

loftux — Wed, 14 Jan 2009 19:25:09 GMT

You cannot disable cifs for a specific folder, you can however "mount" cifs on a lower level, i.e make the cifs start at
Company Home/My Cifs folder
then
Company Home/My web only folder
Is only accessble using the web
Have a look at http://wiki.alfresco.com/wiki/File_Server_Configuration an look for realativepath on how to do this

Re: Versioning for non-supported file types

boden — Wed, 14 Jan 2009 19:53:11 GMT

Thanks, that might work.

Any other suggestions? Certainly there must be other applications out there that delete and write new files on save, so I'm guessing it's come up for someone somewhere.

Re: Versioning for non-supported file types

loftux — Wed, 14 Jan 2009 20:07:39 GMT

I knew I've been part of a similar thread before, and did manage to find it
http://forums.alfresco.com/en/viewtopic.php?p=37333

Hope this answer this for you

Re: Versioning for non-supported file types

boden — Wed, 14 Jan 2009 20:29:26 GMT

Wow, thanks very much.

This means that Alfresco isn't as client agnostic as I had imagined. In my particular case with this one labeling application I can see just working around the limitations…. but what is unsettling is that Alfresco may not work as intended depending on a user's choice of application. The thread you linked to points out the most basic case: a simple text file. Use the wrong editor, and Alfresco falls flat. It's kind of funny because I was just watching the Simple Document Management webinar today and it talks at length about not being tied to any particular client.

This makes the use of CIFS very unappealing to downright dangerous, which is unfortunate because it's one of the "killer" features that got me so excited about using Alfresco.

Re: Versioning for non-supported file types

mikeh — Wed, 14 Jan 2009 20:42:34 GMT

I believe there are specific workarounds in the CIFS code for Microsoft Office, which behaves in a similar way. Obviously, you're at liberty to code similar behaviour for your specific application, but it would be impossible to cover all cases.

Remember, from Alfresco's point of view: file B is being created, then file A is deleted, then file B is being renamed to file A. I'm not sure how you would write a generic case for when a manual operation performing the same tasks would have potentially disastrous side-effects!

Mike

Re: Versioning for non-supported file types

boden — Wed, 14 Jan 2009 23:58:22 GMT

I do understand that the problem is non-trivial. It does seem, however, like there must be some way that it could work…

Consider how the Windows filesystem itself works. If you delete a file and then create a new file with the same name (during the same session as the same user I assume), the creation date of the new file will be the same as the original file. The file contents and properties will have changed, but the file pointer remains the same. In fact this works even if you create a new file under a different name and then rename it to the file you just deleted.

If you see that a particular user deletes a file and then within some time window creates a new file in the same space with the exact same file name, it might not be a bad thing to assume that we want a new version of the (deleted) file…. especially if the original (deleted) file had a versionable aspect. I assume that Alfresco doesn't just completely remove all references to deleted files.

Anyhow, I understand that I'm not going to get a solution here, and I'm not really upset. It is unfortunate, however, because I can't maintain compliance if there is a trivial way to get around an important business rule. Of course this is a problem of accident and not malice, but it's a problem none-the-less.

In fact, it looks like I would have to lock down applications on client desktops to only those approved to work properly with Alfresco CIFS. This creates a dependency on Alfresco and makes the system rely on client configuration over the server. It's not terribly uncommon for an application to delete a file and re-write on save. The thread referenced above mentioned both vi and gedit, and heck even I've written applications that worked that way (blush). The application that actually sparked this thread is Seagull Bartender Enterprise which is relatively new. I can use Alfresco without CIFS (or WebDAV for that matter), but it's a shame because that would have worked so well, especially for stubborn users.