Applies to

• Allegro 2.0 (Allegro RIP 5.1)
• Hummingbird NFS 6.0/6.1

Symptoms

The conflict occurs under these circumstances:

• Where Hummingbird NFS 6.0 (and possibly 6.1) are used to map Unix Server volumes on an NT Server
• Where the Allegro Input directory is located on the Unix Server and is mounted through NFS (no issues with local inputs)
• Once the RIP is upgraded to Allegro 2.0 there is a problem with file locking that does not occur in previous versions of the RIP
• The RIP recognizes and processes the file and outputs to plate or preview as it normally would with the exception of the file being locked on completion.
• Once completed in the RIP, the file cannot be moved by the RIP from the working directory to the done directory and cannot be deleted either.
• Files build up in the input directory and can even be requeued for plate
• At this point the file cannot be moved or deleted in NT File Manager or Explorer
• Quitting the software does not release the file, a system restart is the only thing that unlocks the file
• The Macs, which connect to the Unix server via a different communications protocol, have no problem moving and deleting the same files when they are locked from NT.
• Other files that have not been processed through the RIP can be moved and deleted from NT.

Causes and Workarounds

What we suspect is happening is that the new RIP has a different way of reporting that is it done the file which NFS does not recognize, and as a result this version of NFS leaves the file locked.
The conflict can be resolved by:

• Mapping Unix Server volumes through SAMBA (not a Creo supported product)
• Can be resolved by upgrading to Hummingbird 6.2

Permanent Fix

Upgrading to Hummingbird 6.2 will make this problem disappear.

Technical Contact(s)

Kiarash Owrang

Date Submitted

14 Jul 2000