Error opening text file 0x80070002 (Works on XP)

[dthompson]

I have written a service designed to run on 2003 Servers, in development it works 100% on my Windows XP system. Once deployed to 2003 I keep getting the same error (File Not Found, error 53) EXCEPTION ERROR: 0x80070002

The file is present, I am using FileExists method, if the file is not present no error, if the file is present FileExists = true and the program tries to open the given file. The error results. I have installed the Lastest .Net Framework 2.0 Redistributable (downloaded from MS 17-05-2007) I was using CreateObject("Scripting.FileSystemObject), OpenTextFile("c:\log\bs.log", 1, True)
I have now changed to using StreamReader: Using sr As New StreamReader("c:\log\bs.log") The result is the same, works on XP, fails on 2003.
I can create files and append to files on 2003, but I can't open for read.

Presently downloading SP1 for VS2005 as a last port of call.

I picked up on an old thread back in Nov 2005 with a similar issue works on XP fails on 2003. The thread ended without any resolution.

Dev machine: Windows XP SP2
Server: Windows 2003 Ent. SP1 running .Net Framework 2.0 (v2.0.50727.42)
Coding in VS2005 Visual Basic

[Killer42]

Could this be a simple access error? Perhaps you have write-only access to the file.

(Sorry, my terminology is probably all wrong. Nevertheless...)

If you can check that the file exists then presumably you have "directory scan" access. But not necessarily "read".

[dthompson]

Could this be a simple access error? Perhaps you have write-only access to the file.

(Sorry, my terminology is probably all wrong. Nevertheless...)

If you can check that the file exists then presumably you have "directory scan" access. But not necessarily "read".

Thanks for the response,

I have checked this, initially the Service was running using an account that only had access to the SQL database into which the data is piped. I changed it to a Local Admin account, went a step further and gave all users Full access to the folder and files. The application creates a log file and an error log file, these files are created in the same folder with no issue. Just can't read (can create/append/write).

[Killer42]

Weird stuff. This sounds like it might be one for the Windows forum, more so than VB. Can you try to read the file some other way (that is, other than through VB), just to narrow down where the problems is?

[dthompson]

Just used a VBScript to test it, code as follows, the same as my orginal code in the VB App.
Sub OpenLog
Dim fso, f,strLine,count
Set fso = CreateObject("Scripting.FileSystemObject")
Set f = fso.OpenTextFile("c:\log\bs.log", 1, True)
do while not f.atendofline
strLine = f.readline
loop
msgbox strline
f.Close
End Sub

Works fine, returning the last line of the file in a Msgbox. Run on the server logged in with the same account as that with which the service starts. I also have a Viewer that read the log file, when it is run with the same user, it fails with the same error, unable to read the contents of the file the Service creates. Logging.log

VS2005 SP1 installed, soon will see if that resolves my woes!

[dthompson]

Well to close this up
I have resolved the problem, alas not to sure what the cause/resolution was.
Installed VS2005 SP1. Created a new Test app to open the evil file. Worked fine. Recreated the module in a new module for my existing service. Bob's your Aunty it works. Can only assume that the Service Pack did the trick. Even rebuiling under the new SP didn't work, seems like I had to make a new module to get it to build properly.

[Killer42]

Well to close this up
I have resolved the problem, alas not to sure what the cause/resolution was.
Installed VS2005 SP1. Created a new Test app to open the evil file. Worked fine. Recreated the module in a new module for my existing service. Bob's your Aunty it works. Can only assume that the Service Pack did the trick. Even rebuiling under the new SP didn't work, seems like I had to make a new module to get it to build properly.

That is weird. Oh well, I suppose the important thing is that you've got it working. It would be nice to know what happened, though.