file already locked in mixed C++/CLI code?

  • Thread starter Thread starter emarkp
  • Start date Start date
E

emarkp

I'm using an aging library that I can't port to .Net. It reads a file
and parses it into a structure.

The problem I'm having is that in a mixed assembly (/clr) when I call
the library, it returns an error saying the file is locked. Problem
is, it only gets locked when I try to load the file.

I can replicate the problem with fopen--the open fails saying the file
is already locked, but it's fopen that's trying to lock it in teh
first place.

Has anyone run into this? Is there a general solution?
 
I'm using an aging library that I can't port to .Net. It reads a file
and parses it into a structure.

The problem I'm having is that in a mixed assembly (/clr) when I call
the library, it returns an error saying the file is locked. Problem
is, it only gets locked when I try to load the file.

If you're not making use of the file elsewhere there's no reason why
it should fail - so the question is where else is it getting accessed?
Have you had a look at what's happening with the SysInternals FileMon
utility?

Dave
 
How you access the files in .Net? Are you disposing the disposable objects?

I'm performing all directory and file listing operations using the
File:: and Directory:: static functions. I'm not using the objects,
precisely to avoid unnecessary locking.
 
If you're not making use of the file elsewhere there's no reason why
it should fail - so the question is where else is it getting accessed?
Have you had a look at what's happening with the SysInternals FileMon
utility?

Dave
 
If you're not making use of the file elsewhere there's no reason why
it should fail - so the question is where else is it getting accessed?
Have you had a look at what's happening with the SysInternals FileMon
utility?

It's not getting accessed elsewhere. When running FileMon, it's the
only process accessing the file, and it reports a successful open and
then close. Something in the library is reporting a failure. When I
compile the module as native code, it works fine.
 
If you're not making use of the file elsewhere there's no reason why
It's not getting accessed elsewhere. When running FileMon, it's the
only process accessing the file, and it reports a successful open and
then close. Something in the library is reporting a failure. When I
compile the module as native code, it works fine.

OK, can you supply a self-contained source example (a small console
project) that illustrates the problem?

Dave
 
OK, can you supply a self-contained source example (a small console
project) that illustrates the problem?

Afraid not. It's a proprietary library. All I'm doing is providing the
filename to the library entry point.

As it stands, we've found an an alternate library and (with source)
and it looks like we'll just be ditching this lib.
 
Back
Top