> Just a short note: apparently it is not a good idea to place
> a Microsoft Outlook 2000.PST Personal Folders file on an AFS
> disk. Repeated data corruption, requiring Inbox Repair Tool.
>
> I'm not terribly surprised. I'm guessing different lock semantics.
as many have responded, file locking must be the culprit.
However, I am still a bit surprised. As you may know, one of UNIX's big
"contributions" to OS development was making concurrency control optimal.
Instead of automatically requiring the appropriate form of locking - read
locking, write locking, whatever, like you had to specify on mainframe OSes
- early UNIX is had no concurrency control at all and you had to
do-it-yourself. In V6 and V7 this work surprisingly well. Locks only got
added later.
Moral: most apps didn't need concurrency control, as long as the user made
sure that only one user was accessing a file at the same time.
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.
In fact, I'm more than a little suspect that the problem is that AFS
does not return a clean "success" lying status code to these requests. i.e.,
if the app isn't multithreaded then AFS's blocking semantics shouldn't be a
problem; returning success inaccurately should not stop the From running.
But not properly returning success would be a problem.
Anyway, no worries: just one more piece of data that I can place on AFS.
