Quantum SDLT 600A continued...

Having upgraded and shipped a few of these (see here) we're starting to get customer feedback;

One of our editors has been busy with it since it arrived on Monday and ran into some problems. We then brought in our system's administrator to help him sort a few things.
It turns out that in general it all seems to work, but there are some majors faults that prevent us from using the device the way it is supposed to be used (and the way we would like to be able to use it).
This is the way the 'bugs' were explained to me:
When copying a project folder (with different files in there) to the drive onto a cartridge, it will alter the original date the files were created to a fictional date that the 600A seems to refer to. On copying it back to our systems, the files will again alter the dates to the system settings of the computer at that time.
This makes it impossible to distinguish between different FCP project files etc. thus making it very hard (if not impossible) to recognize the most recent edit if it was not named perfectly (lot's of times we like to refer to the 'date modified' for reference).
The only workaround we have for this, is to Archive the project folder first, so only the date of the Archive gets affected and the contents will be left untouched. The disadvantage is of course that we now have to take off the entire project folder and unpack it, before we can access the necessary files.
The other problem is that if a certain file has a slightly longer name, or a space or underscore in the name, it will copy to the tape just fine, but it will not let you copy it back to the computer from tape. The only workaround for that is the same as for the other problem, i.e. Archiving it before backing it up, so only the Archive name gets 'noticed'.

Hmmm - I'd never rely on a remote filesystem to keep dates accurately - particularly since you may be going between different filesystems that might mangle filenames, permissions etc. Anyhow - the word from Quantum;

I have done some investigation into this "bug". This is normal behaviour for FTP and therefore we need to think around this.
Technically we can preserve the file attributes in the metadata fields as a future enhancement.

So there you go - an workflow adjustment me thinks.