Dean Knape <knape@njit.edu> wrote:

Jeffrey Altman wrote:

Something to note.  You are attempting to run a 32-bit exe from
64-bit Server 2003.  I wonder if that is a variable.

I was thinking same but everything runs fine on my base image.  It's
only after a sysprep that
things fall apart.

Hmm...  Did you completely DELETE the %TEMP%\AFSCache file before 
cloning the system?  This is specifically mentioned in the release notes 
and weird things happen if you have multiple systems based off of the 
same image.  The AFS uuid is stored in the cache file and multiple 
machines can look like the same client if these are not unique.

According to your reproduction steps, you need to sysprep the vmware
image.  Is that really a requirement for reproduction?

This avoids the duplicate SID and AFS UUID problem.

Sysprep by itself does not take care of duplicate UUIDs.  You need to 
delete the AFSCache file.

Or run fs uuid -generate

<<CDC 

If you set that value to 0, then winword will start but two users on
different machines will be able to open the file at the same time.
Doing so will corrupt the file if both decide to write to it.

Jeffrey Altman

Hans Melgers wrote:

Thanks Jeffrey.  The older version was in the early stages, we found it
also happens with 1.5.25.  On some pc's this happens, on others it doesnt.

So the problem is in winword trying to obtain a lock indefinitely.
What do you recommend ? is there any (registry) setting that does this ?

Would this be a solution ? I mean, would winword accept and act on
changing this setting to 0 ? :

If the CIFS-AFS server is unable to renew the AFS file server locks,
then it will invalidate the associated file handles.  This is the same
behavior that an application will experience if it was using a Windows
File Share and the connection was broken.   Invalidating the file
handles prevents subsequent data corruption from taking place.
If you wish to disable the acquisition of locks from the file server,
this can be performed using the EnableServerLocks registry value.

Value: EnableServerLocks
Type: DWORD {0, 1, 2}
Default: 1

Determines whether or not the AFS file server is contacted for

0: never obtain server locks

1: obtain server locks unless the file server says not to

2: always obtain server locks

_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Hello everybody,

I'm new here... I want to ask you a question: I'm trying to install an afs-client using Scientific Linux Cern 4.5. The problem is that I think i've done everything right, but when I reboot my computer, the CellServDB changes alone, and doesn't contain the new servers that I added. I've tried with fs newcells but it stills changes on reboot... and it doesn't work...
any idea???

Lara
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Therefore, if you are providing files to be used simply as read only
templates, they should be stored in AFS in a manner that indicates to
the AFS client that they are in fact readonly so that the cache manager
knows it is safe to fake the locks locally.
Jeffrey Altman wrote:

If the files are truly intended for read-only use, store them in a
directory that provides only 'rl' access to the end users or store them
in a .readonly volume.   In both of those cases the AFS Cache Manager
knows that the user cannot obtain a lock on the file and will issue one
locally.

Jeffrey Altman

Now that I am back in my own timezone let me take the time to explain a
bit more about locking and Microsoft Office applications.  Office
applications will obtain an exclusive lock on a file even when the file
is being opened in "read only" mode.  OAFW will translate "file open for
read and not write and not delete" and "request for exclusive lock" as
meaning "obtain a read lock on the file".

The problem that you are experiencing is that while the Office
application is requesting a lock for a very small subset of the file,
AFS only implements full file locks.  If Office applications are two
machines attempt to open the same file and the first one has the file
open for write, the second one won't be able to open for read because
lock requests that otherwise would be non-intersecting byte ranges
collide when translated into full file locks.

Therefore, if you are providing files to be used simply as read only
templates, they should be stored in AFS in a manner that indicates to
the AFS client that they are in fact readonly so that the cache manager
knows it is safe to fake the locks locally.

Jeffrey Altman