Jan 14

Alfresco Network Shares and Preserving File Dates

Note:  The Mac solution here is broken as of OSX 10.10.2.  See here for other approaches.

Many use cases call for CIFS, SMB or WebDAV access to Alfresco ‘shares’, particularly for migration and interoperability scenarios with legacy file stores.  It is fairly well discussed that the default behavior is to assign a new file creation date on the Alfresco side for the date/time that matched the system date/time when the content is moved or copied in.  This scenario causes the loss of potentially valuable metadata (the original created/modified dates) that, in some use cases, is a potential ‘show stopper’.  Often such metadata is essential for understanding the history, version status, etc. that dates reflect.

A search through the Alfresco forums and various Googling turns up that this has been a noted problem (for some) for quite a while and ultimately won’t be ‘fixed’ because it is an intentional design decision.  There are apparently solutions that involve dreaded custom coding to the applicable API, but those are not realistic for most.  It took a bit of work, but below are work-arounds for a couple of cases.


The Windows work-around was fairly easy to find, and in fact already discussed in some older Alfresco Forums posts, but here is my spin.  RoboCopy is a command line copy utility for Robust File Copy.  It has many features, but relevant here is the /:copy T flag which preserves timestamps.  Rather than muck about with the command line, there is a successor that is a few years old called RichCopy that worked for me.  Unfortunately the workflow approach is more of a directory/bulk copy one than a file level handler.   There are some reports that a Windows port of Rsync, TeraCopy, FreeCommander and the like may also work.  I haven’t tried any of those, so YMMV.


Like many things ‘Enterprise’, finding a Mac solution was a bit more convoluted.  As this was the specific problem I was asked about, I stuck with it and ended up finding a solution even better than the Windows solution.  I tried a LOT of solutions suggested as providing RoboCopy like features for Mac.  All failed for various reasons, mostly relating to finicky OSX mounting of the Alfresco Share.  Ultimately the solution that worked was using a Java based file manager called muCommander.

On a fresh Yosemite install, I ran into a few hiccups.  First, I needed the applicable Java version, found here.  Next, OSX threw completely useless errors describing muCommander as “broken” and needing deletion or “not working on this Mac” and the like.  These utterly unhelpful (deceitful, even) messages all related to the fact that OSX security settings prevented the application from running.  This was easily changed in System Preferences | Security & Privacy.  You should know what you are doing before changing those settings, but that doesn’t mean you shouldn’t be told that they are there.

MuCommander allows you to mount the Destination SMB share to Alfresco easily, and apparently by default preserves file timestamps.  It also has a more granular, file level left/right type GUI as well. Problem solved.

…come to think of it, since this is a Java app, I’m going to try it on Windows as well and report back later.