Any more word on the vdm*.tmp file issues?

[Chip Reinhardt]

There have been a few threads here about 16bit apps running under W2K/XP
with 4.83client creating zero-byte vdm*.tmp files in the working
directory. This does NOT appear to be a client SP1 problem, but instead
a W2K SP3 problem.

Anybody have a fix for this? I have created some batch files to delete
the *.tmp files, but it is certainly an annoyance.

Chip Reinhardt

[Hamish]

Chip,

I've asked one of the posters with the problem for some extra detail -
namely, does it occur with Dos and/or Windows 16 bit apps, does it happen
without the Novell client installed - ie to a MS server using the MS client,
or to a Netware server using the MS Client for Netware. If you're able to
answer I can pass it on to my contact at Novell.

--
Hamish Speirs
Novell Support Forums Volunteer Sysop.

(No email unless requested please)

[Steven Wilson]

Hamish,
on the testing we did on our network this is what we found.
the vdm*.tmp files only occurred in 16 bit Windows and Dos apps located on
the NW file server
the vdm*.tmp files were only generated from Win2k SP3 machines with 4.83SP1
clients
backrev to 4.83 with patches and all was fine
we have several Win2k SP2 machines running 4.83SP1 with no problems at all

I chatted with a guy in Germany that has been dealing with this on a pure
Win2k network.
They have had this problem long before SP3 - it goes like this...
First person using Win2k to open the 16 bit app creates a temp file
~user.tmp in that network directory. Then a second user starts the same app
and his workstation renames the ~user.tmp to VDM???.tmp. Every time another
users starts the app this happens again until the program runs out of
licenses. The original workstation is looking to delete ~user.tmp when
closing the app, but cannot find it since it has been renamed. The second
workstation is looking to delete a ~user.tmp file on exit, but does not find
it either since it has been renamed. Then someone has to manually delete the
VDM???.tmp files before anyone can get back into the program.

M$ official answer to them:
Change the System Variables 'temp' and 'tmp' to %USERPROFILE%\TEMP instead
of %SystemRoot%\TEMP
He said the change has to be made to the System Variables and not the User
Variables. He also said this has had limited success - it could not help
programs that required a temp file (such as a license lock file) be placed
on a network drive.

Apparently it's a Win2k problem and the guys running M$ networks have been
dealing with it for a while.

that's all I know...
Steve

"Hamish" <Ham...@speirs.mine.nu> wrote in message
news:3D87C337...@speirs.mine.nu...

[Hamish]

Steven,

Thanks for the details - I'll pass it on to my contact at Novell who's looking
at the problem.

[geoffs....@otcnetworks.invalid.com]

> Steven,
>
> Thanks for the details - I'll pass it on to my contact at Novell who's
looking
> at the problem.
>

I wouldn't look too hard for the problem, it doesn't have anything to do
specifically with Novell. I know this because a Win2k (with no service
packs) that is on an MS-only network will do the same thing running a 16-
bit DOS app that I wrote. I worked around it in my app by having it check
for and delete the VDM*.tmp files on a regular basis.

The files are created any time my 16-bit DOS app tries certain types of
access to a file that another user on the network has opened in 'LOCK
WRITE' mode and it may also occur when a 16-bit app tries to lock a
record/byte-range that another process has locked. I didn't bother to
isolate exactly what type of access was required to create the problem and
I haven't tried to duplicate it using any Win2k SP's because it appeared
to me to be debugging code MS left in the VDM and I figured it would get
fixed in a Win2K sp. I think I was able to duplicate the problem without
using any networking by opening a file on the local workstation with
Notepad and then having my app try to open the same file, but I don't have
written notes on exactly what I did test. I do know that I put my work-
around in place on 2002-11-18 so the problem has existed for more than 2
years and doesn't have anything to do with Novell.

[Chip Reinhardt]

Hamish,

I don't have a MS server, only a NW server, so can't answer that question.
Haven't tried access with the MS Client for Netware.
I did backrev to Client 4.83 without SP1, no success, still plenty of vdm*.tmp
files. It occurs every time the 16bit Win app tries to save to the network
disk.
I didn't have these problems with 16bit DOS apps until W2K SP3, so I expect it
is somehow related to SP3.

Chip Reinhardt