Mitch Collinsworth wrote: > Which leads into a different question: Is there any reason not to start > off by upgrading one or more of our fileservers from 1.2.13 to 1.4.4, while > leaving the database servers at 1.2.13 until sometime later?
There is no specific requirement that one be done before the other. We haven't changed the data formats or protocol exchanges up to this point. > For completeness I should state that the prime motivation here is to get to > a point where our Windows users can begin taking advantage of file locking. > (Obviously their client binaries need to be up to date, too.) File locking is simulated in the client. The client obtains a full file lock from the file server and then doles out byte range locks locally to the application. The change in the file server from 1.2.13 to 1.4.5 will provide you with large file support and a modification to the locking semantics so that users that have 'w' permission do not need to explicitly have 'k' permission. Of course, if you have already granted 'k' permission to your users there will be nothing gained. Is there something else you were thinking of?
smime.p7s
Description: S/MIME Cryptographic Signature
