Closing local and remote file connections

[blakecaraway]

Hi there.

I have a C# console application that extracts data to flat files. Some
of my business partners begin consuming these extract files before I've
had a chance to write the newest ones (I am extracting these files once
a day beginning at midnight). Since one or more consumer has a
particular extract file open, I need to detect this and then take
action to close all open file connections so I can put the new extract
file out onto the network share where the extracts reside.

I've managed to use the psfiles.exe (from sysinternals.com) and write a
C# class that runs the psfiles.exe in a separate process, captures the
standard out (or standard error) and then parses this output into a
custom OpenFile object containing the process ID and user that has the
file open.

This seems to work okay. It seems like a rather large hack, though.
This method also suffers from a limitation. From what I can tell (and
I've tried several ways) I cannot get info about files opened on the
system where I'm running my console application from - much less close
the connections to any local files.

I've started looking into calling the Win32 API calls (i.e.
NetFileEnum, NetFileClose and others) using DLLImport from C# but I'm
afraid I have no C/C++ coding skills to speak of.

Does anyone know of another small utility/.exe that gets both remote
and local open file connection information, and allows the closing of
the open file connections? If not, is there some type of beginner's
tutorial that I can read that can get me started with C# Win32 API
coding?

Thougths? I appreciate any help.

Thanks in advance,

/bc

[Dincer Uyav]

Hi,

You can easily overwrite the file even if it is used by someone else by
creating the filestream like this :
File.Open(filePath,FileMode.Create,FileAccess.Writ e,FileShare.Write);

hope this helps

Dincer Uyav
di********@teknainternational.net

"bl**********@gmail.com" wrote:

Hi there.

I have a C# console application that extracts data to flat files. Some
of my business partners begin consuming these extract files before I've
had a chance to write the newest ones (I am extracting these files once
a day beginning at midnight). Since one or more consumer has a
particular extract file open, I need to detect this and then take
action to close all open file connections so I can put the new extract
file out onto the network share where the extracts reside.

I've managed to use the psfiles.exe (from sysinternals.com) and write a
C# class that runs the psfiles.exe in a separate process, captures the
standard out (or standard error) and then parses this output into a
custom OpenFile object containing the process ID and user that has the
file open.

This seems to work okay. It seems like a rather large hack, though.
This method also suffers from a limitation. From what I can tell (and
I've tried several ways) I cannot get info about files opened on the
system where I'm running my console application from - much less close
the connections to any local files.

I've started looking into calling the Win32 API calls (i.e.
NetFileEnum, NetFileClose and others) using DLLImport from C# but I'm
afraid I have no C/C++ coding skills to speak of.

Does anyone know of another small utility/.exe that gets both remote
and local open file connection information, and allows the closing of
the open file connections? If not, is there some type of beginner's
tutorial that I can read that can get me started with C# Win32 API
coding?

Thougths? I appreciate any help.

Thanks in advance,

/bc

[blakecaraway]

Thanks Dincer.

I tested out your recommendation, but no dice. I tried to do a:
File.Open(filePath,FileMode.Create,FileAccess.Writ e,FileShare.Write);

while the file I was trying to "Open" was simultaneously open for
consumption from a DTS package, but the same exception was thrown
claiming that the file is in use by another process.

However, when I changed the FileShare mode to ReadWrite, I was able to
overwrite the "locked" file despite other processes having it open.
After that, I was able to delete that file so my extract process could
re-create it with the current day's data.

Thanks for the help! That sure beats having to run a third-party .exe
and capturing/parsing the output and then manually killing the file
connections by process ID.

Thanks again!

/bc

[blakecaraway]

Oops. I stand corrected. Apparently using File.Open as I stated in my
previous post DOES NOT work. I could have sworn I saw it work this
morning while unit testing the File.Open method you (Dincer) suggested.
It wouldn't be the first time I missed something so obviously binary -
either it works or it doesn't. So....it's back to the drawing board.

Apparently there doesn't seem to be any way - short of killing the
process ID - of getting access to a file that another process has open.

Using the utilities (Handle.exe, PSFile.exe, and PSKill.exe) from
sysinternals.com seems to give me ability to kill both remote and local
open file connections successfully. The only bad part is that I'm
writing a C# class that calls third party .EXEs to do the work and
parsing the output for informational purposes (logging). It definitely
smells bad, but it's probably faster (i.e. development time) to do it
this way than to learn how to slog C#/Win32 API code and wind up
writing my own custom wrapper that does the same thing.

If anyone has any further info/help regarding this issue, I'm ready to
listen. Now, I'd better get started on this hack of a solution.

Thanks,

/bc