At 03:44 PM 7/28/00 -0500, you wrote:
>> Now, I am 100 percent sure that I was the only person accessing my
>.PST
>> file. For AFS's lock semantic limitations to cause a problem, it
>implies
>> that the Microsoft outlook application is actually multithreaded and
>that
>> multiple outlook threads are accessing the data at the same time. this
>is
>> possible; I have heard that M.S. apps are multithreaded, but I am
>still
>> slightly surprised.
>
>We've seen other apps, wherein some subtler aspects of its function
>would simply not operate properly if accessing AFS via the Transarc
>client for NT, but would work properly if accessing AFS via Samba.
>
>We conjectured that this may be a result of the sometimes-inaccurate
>handling of UNC names by the AFS-NT client. Some apps may utilize
>mapped-drive paths internally for some functions, and UNC paths for
>others (modules provided by different programming teams), which creates
>a case where only some portions of an app's features would be
>incompatible with [Transarc-client-accessed] AFS.
>
>
We have also seen this problem with all the AFS NT clients and patches with
respect to Outlook PST file storage. We've done some investigation and
found some significant information. The problem appears to be a symptom of
the AFS NT client not writing the full file back to the AFS file system.
NT, or should I say the AFS local cache, appears to have the right
information, meaning that if you restart Outlook right after a close, it
should work fine. But, if you close Outlook and view the AFS file on the
file system by looking at it via another UNIX box you will see that the file
will not always be properly stored. We see it as a difference in the length
of the files (the one stored on the local cache, and the one in the AFS file
space). So if you shutdown your NT box, or the AFS client service is
restarted, you will re-read the file stored on the AFS file system instead
of getting the local cached copy. You may then start Outlook and see a
corrupted copy. This may be a sparse file problem because upon examination
we found that what isn't being stored is a bunch of NULLs on the end of the
file.
My administrator found an obscure article on Microsoft's knowledge base that
-seems- to fix the problem with Outlook 2000. I'm not sure there's a fix
for older versions of Outlook. The article is...
http://support.microsoft.com/support/kb/articles/q245/7/76.asp?LN=EN-US&SD=g
Now, I'm not making any guarantees here. I still blame the AFS NT client
for not properly flushing the file. We've tried flushing the volume and the
file by hand and it didn't work.
I hope this clears up any confusion. The problem does not appear to be
related to a locking issue.
Hope this helps. :)
Rodney
Rodney M. Dyer
NT Systems Programmer
Mosaic NT Network Group
College of Engineering
University of North Carolina at Charlotte
Email: [EMAIL PROTECTED]
Phone: (704)687-3518
Help Desk Line: (704)687-3150
FAX: (704)687-2352
Office: 267 Smith Building
