Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

FileSystemObject's FileExists function returns false for existing files

609 views
Skip to first unread message

Zhiguo

unread,
Dec 15, 2009, 2:40:10 AM12/15/09
to
Hi, my friends:

Strange things happen when I use Scripting.FileSystemObject to read
local files.
For an existing file, sometimes FileExists returns true, and sometimes
it returns false.

=====My program is like this:
(1) Main program is an .exe file;
(2) The main program calls a .js file using the following sentence:
::ShellExecuteW(NULL,L"open", LPCWSTR(wstrCmdLine.c_str()), NULL,
NULL, SW_SHOW);
where wstrCmdLine is the path of the .js file.
(3) The .js file read the whole content of files using the snippet at
the end of this message.

=====The problem is:
(1) When I run the main program for the first time, everything is OK,
no matter how many times I call ReadAllContentFromFile function.(code
given in the end of this message)
(2) When I restart the main program, the .js file become unstable:
sometimes it reads file ok, while othertimes the FileExists function
of Scripting.FileSystemObject return false for the same existing
files.
(3) Notice that all the files are only read in the .js functions. It
is not necessary to write files.

My guess is:
(1) The main program file to release resources related with
Scripting.FileSystemObject, although I am sure that no wscript.exe
process is running after the main program ends.
(2) I have tried this: store the content in an .xml files and use
Microsoft.XMLDOM object to read them. However, similar things hapen:
When I restart the main program, Microsoft.XMLDOM object also fails
to read the .xml files.

=====Ask for help:
Wy does this happen?
How to solve this problem?
Thanks in advance!
Looking forward to your reply!
Any help will be appreciated! :)

//here is my code:
function ReadAllContentFromFile(strFileName){
try{
var objFSO = new ActiveXObject
("Scripting.FileSystemObject");
var vFileContent = "";
if (objFSO.FileExists(strFileName)){
var vFile = objFSO.OpenTextFile(strFileName,
1, false,0);
vFileContent = vFile.ReadAll();
vFile.Close();
}else{
vFileContent = "NOT EXIST: " + strFileName;
}
objFSO = null;
return vFileContent;
}catch(error){
return "EXCEPTION: " + error + "@" + strFileName;
}

Richard Mueller [MVP]

unread,
Dec 15, 2009, 12:57:43 PM12/15/09
to

"Zhiguo" <zhigu...@gmail.com> wrote in message
news:2197fa8a-0996-4582...@v15g2000prn.googlegroups.com...

I know nothing of js, but have never heard of the FileExists function of the
FileSystemObject exhibiting erratic behaviour. However, things can go wrong
if you open files and then fail to close them (until you restart the
computer). Do you always close open files?

--
Richard Mueller
MVP Directory Services
Hilltop Lab - http://www.rlmueller.net
--


mr_unreliable

unread,
Dec 16, 2009, 9:01:42 PM12/16/09
to
Richard Mueller [MVP] wrote:
> I know nothing of js, but have never heard of the FileExists function of the
> FileSystemObject exhibiting erratic behaviour. However, things can go wrong
> if you open files and then fail to close them (until you restart the
> computer). Do you always close open files?
>

There may be another possibility.

I don't really know what goes on inside fso's fileexists
or fileopen, but I have had problems (access denial) when
another app happened to want to use the same file I was using,
and put a lock on it (even though he wasn't writing it).

In other words, the file may be getting locked but not
unlocked.

cheers, jw

mr_unreliable

unread,
Dec 17, 2009, 1:52:42 PM12/17/09
to
mr_unreliable wrote:
> There may be another possibility.
>

For some other possibilities, look here:

http://support.microsoft.com/kb/245068

Note also the reference to the sysinternals utility
called "Handle". It may be used for debugging who
has grabbed onto your file, and why.

http://technet.microsoft.com/en-us/sysinternals/bb896655.aspx

cheers, jw

Paul Baker [MVP, Windows Desktop Experience]

unread,
Dec 21, 2009, 3:29:05 PM12/21/09
to
You may find Process Explorer easier to use than Handle. It too is f rom
SysInternals.
http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx

The file being open should not cause this kind of issue. Think about it. You
don't get inconsistent results when you open a Windows Explorer window on a
folder or use DIR at the command line, regardless of whether or not a file
in the folder is in use.

Paul

"mr_unreliable" <kindlyReply...@notmail.com> wrote in message
news:%23XjTvl0...@TK2MSFTNGP02.phx.gbl...

0 new messages