A number of sporadic problems of AutoCAD users who've been working away
suddenly not able to write to the file they've been working on. If
multiple people try to use the same Xrefs, often some will get that the
file is corrupted report by AutoCAD.
What is reproducible is one of the Xref problems and it has given us a
bit of a work around to keep working.
To Reproduce:
Start AutoCAD(2009), open a file with base(Xref)
Save the base (no change needed) without closing, and refresh
the base disappears from view, and when we look in the 'Xref Manager'
we see that the Base has a status of 'Needs Recovery'. This applies
even when multiple people had the Xref in read only view, that it is
now unavailable, but when the full drawing is shut down and reopened
by the one who had saved, the Xref is just fine.
Autosave is not triggering the problem.
This has been reproduced on the newest version of ACAD as well, just
slightly different wording of errors.

OES2 sp3 servers (in VMWare) with mostly XPsp3 clients but a few
Windows 7 ones as well. The clients mostly have the newest clients
installed, but there are some of the XP boxes with 4.91.4 still on
Just migrated the main data volume from NetWare 6.5.8 to OES2 Linux and
immediately started having the problem. 100% of file access is via
NCP. no CIFS is configured, to the point we have cross-protocol-locks
set to 0 (Zero, i.e. Off).

I think I've been through every combination of file locking settings of
server vs workstation without any apparent change.
Still working out different tests to do to find what makes a

Observations that might just lead to clues toward the root cause:
- On NetWare, if a user left files open over night, we could still see
those being listed as opened in Monitor. Past history with these users
is that there was always several showing as open every night even when
we were sure they'd all been gone for hours. Now when we check the all
the volumes late in the evening, they've been showing no files open.
perhaps that is a clue to a problem in lock tracking.
- While still at OES2 sp2, the pilot team kept giving vague
descriptions of problems using ACAD against files on OES2, but those
all went away after applying SP3, so after 2 months of one small group
running ACAD against files stored on OES2-linux, we migrated the bulk
of the data as the last volume from a failing NetWare 6.5.8 cluster
(recreating SBDs was getting tiring).

Andy Konecny
KonecnyConsulting.ca in Toronto
Andy's Profile: http://forums.novell.com/member.php?userid=75037