I have a question to what, for me, is an absolute show-stopping issue.
Using all methods of access, CIFS/WebDAV/web interface, to access Alfresco is there a global way (as in set it once for an entire volume) to ensure that the creation date and the modified date of any file copied from a traditional file system to Alfresco is preserved and maintained? A natural progression of that question is can the same be said when copying a file from Alfresco to a traditional file system?
For any installation of Alfresco into an organization to replace windows file services there must be a ‘get comfortable’/acceptance/pilot phase, which means the solutions have to coexist. The smaller the size of the business the more true this is, since a small business is less likely to have the resources to forklift over to Alfresco. Users rely primarily on two methods to determine whether a given file is what they want, short of opening it: file name and the dates. Also, when users do their own manual backups or versioning, they use dates as a determinant. Certainly the software they may use will. While you may argue that Alfresco can do a better job than users or other software, this is a chicken and egg scenario, beginning with preservation of the vital basics: names, dates, & content. The dates (other than last accessed) of a file, unchanged by a user, have to be immutable across a network or organization.
After pouring through these forums I am more confused now than before. I keep reading entries containing arguments about metadata and items external to Alfresco. Then there is the supposed need to do things one file type at a time. File system dates are metadata. They are a universal attribute of all files. Before I care about the metadata inside my word or PDF document, I need to care about what the file system says. Also I’ve heard arguments that Alfresco doesn’t handle dates external to Alfresco. Well my network is my entire problem domain, not a single product. If Alfresco is to be part of the solution it needs to work in that entire space rather than take a NIH approach.
Can anyone help with this or clear up possible misconceptions for me.
But I think its worth raising an Enhancement request for this.
From looking at these forums the discussion seems to have got hung up with setting alfresco's read only properties which of course you quite rightly shouldn't be able to do. However the crucial insight for me is that the file system projections probably shouldnt be tied to the meta-data's cm:created and cm:modified properties.
I found https://issues.alfresco.com/jira/browse/ENH-312 and added a link to this thread.
thanks for the response. i'm looking into the link you provided.
do I understand it correctly that it is still not possible to preserve the original document dates when inserting into Alfresco ? Or is there now (version 3.2 and above) a solution available ?
Agreed. This might be a showstopper, having to custom develop something which is that basic.
This issue is nothing short of a major show-stopper. Because of the inability to do something so basic and essential I had to walk away from the product. Now though we are up to version 3.4, where the version was 3.2 when I first asked. Has anything changed? Has this most basic need and product oversight been fixed yet?
I've just tested 4.0a and it would appear this problem still exists. While I can appreciate the comment by MikeH from Oct-2010, the inability of Alfresco to preserve something as fundamental and essential as creation and modified date from the source file system is a non-starter.
Is it possible I missed something in configuration?
These issues have been well covered in Martin Bergljung's book Alfresco 3 Business Solutions (Packt) in the section starting pp346 on Document migration.
Not saying all the answers are there but the problems are understood and some solutions provided.
One tool you could investigate and try is the Bulk Upload Tool http://code.google.com/p/alfresco-bulk-filesystem-import/.
This is changed to make it possible in, I think 3.4. As you note above the bulk import works, as do tools like RoboCopy over CIFS.
There still may be some use cases that don't or can't work, these need identifying and looking at.
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 through 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.
Since this thread has come up again I thought I should also mention that there's an option in FileZilla to preserve original dates that works with Alfresco's FTP service.
First, thanks to MRogers for the FTP tip (haven't tried it yet as I typically have FTP off on installs).
Apple seems to be regularly messing with the SMB implementation in OSX, probably in attempts to make sure Macs play nice with NAS devices and windows shares. In any case, Apple made changes in OSX 10.10.2 and as of that OS, MuCommander on Mac no longer preserves file creation metadata from legacy file systems. I now can't find any SMB or WebDAV approaches or applications to address this directly in MacOS.