Help with FileAppend.

[morenos1]

Simple script which worked for a long time.

I get a 1014 Fileappend I/O error when running this script.

IF FileExist("\\server\share\wstations.all")
FileDelete ("\\server\share\Wstations.all")
EndIf

FileAppend("\\server\share\*.txt", "\\server\share\wstations.all")
Display(5, "I N F O", "Output text file WSTATIONS.ALL has been created...")

Nobody is accessing the output file .....

[Deana]

FileExist will return the value 2 if the file is in fact in use. This code can be used to determine of the script thinks the file is in use:

Code (winbatch) Select Expand


DebugTrace(@on, 'trace.txt') ;DEBUGGING ONLY
ret = FileExist("\\server\share\wstations.all")
if ret == 1
   FileDelete ("\\server\share\Wstations.all")
elseif ret == 2
  Pause("Notice","File is ucuurently in use...")
  Exit
endif

FileAppend("\\server\share\*.txt", "\\server\share\wstations.all")
Display(5, "I N F O", "Output text file WSTATIONS.ALL has been created...")
Exit

If the code still fails, post the resulting trace.txt file.

[morenos1]

Trace file ...

[Deana]

I was hoping the trace.txt file would contain extended error information. However most of the extended information is stale and left over errors from previous versions of WinBatch.

Does the error message offer the option to select a button titled "More Error info"?

You also mentioned that this script has been working fine. What has changed exactly? Are you still running on the same workstation using the same user account? Can you confirm that the remote directory or files are not Read Only.

[morenos1]

The "More Info" is greyed out.

The files are not "Read Only".

The output file gets created with 1 line of text only.

I can not remember the last time I needed to run this script and, it worked.

A lot has changed, (windows updates, WinBatch updates) this is a Win7 system.

[Deana]

Wait I thought you were getting an error? Are you saying you get an error yet the output file still gets created?

Start by manually deleting the wstations.all file on the remote share. Test again.

[morenos1]

I tried deleting the file already.

Yes, I get the error but, still the file gets created with just 1 line appended ...

[Deana]

Okay if you still get the error even after manually deleting the target file I suspect the script is unable to open/read one of the *.txt files.

Maybe use this code to track down which file is causing the issue:

Code (winbatch) Select Expand

filelist = FileItemize("\\Server\Public\FileAppendTest\*.txt")
For x = 1 to Itemcount( filelist, @tab)
    file = ItemExtract( x, filelist, @tab )
    ret = FileExist( file )
    if ret == 2
     Pause("Uh oh! File is currently in use...", file)
     Exit
   endif
Next


[morenos1]

I ran this. It did not find any problems .....

[Deana]

I am running out of ideas. I am beginning to suspect a hardware issue, when trying to access the remote network share. I will need to consult with the developers on this one.

You mentioned that this code has previously worked....What has changed if anything?

[morenos1]

Just Windows7 Windows 2008 on the server side .....

If I direct the script to a different machine, the error still comes up ...

The file gets created with just 1 line.

If I point the file to a local drive, it runs fine ....

[Deana]

Maybe try troubleshooting your network adapter: http://windows.microsoft.com/en-us/windows-vista/troubleshoot-network-adapter-problems

[morenos1]

Thank You. I will look into my PC ........

[td]

Just Windows7 Windows 2008 on the server side .....

If I direct the script to a different machine, the error still comes up ...

The file gets created with just 1 line.

Fine but you left out an important detail i.e., what was  the source of the contents of that line? Is the line nothing more than a CRLF, is it the first line of one of the text files being appended or is it the entire contents of a file?

If I point the file to a local drive, it runs fine ....

Windows 7 and 2008 are  big differences.  The source of many Windows 7 related problems is UAC.  Many folder share issues are permissions related.  You can try to diagnose these issues by manually attempting to perform some of the tasks your script is performing.  For example, you can try to open a text file on the share in a standard text editor with the same account and elevation level as your script runs under.  If that works, you can try editing the file and then checking if you have permission to save it.

Another source of shared folder problems, as previously alluded to, is hardware issues.  These are hard to diagnose because they can be either intermittent or only occur under a difficult to determine set of circumstances. 

FWIW, I did use your script successfully after substituting server and share values appropriate for my LAN  on a Window 7 system accessing a share on a Windows 2008 server.
   

[td]

Forgot to mention another known cause of folder sharing issues.  In th resent past there has been at least one case of a well known anti-virus utility with a buggy device driver hook that caused share read/write access problems somewhat similar to what has been describe here.  Fortunately in that case, the problem had already been reported to the the providers of that software and they had a software update available to correct the issue.   

[td]

...and since the 1014 error only occurs when a file read or write is attempted there is some remote possibility that one of the files being accessed is corrupt because of a bad disk sector or something.   

[Deana]

Based on Tonys response about a possible corrupt file...You could maybe use this code to see if each of the txt files are readable:

Code (winbatch) Select Expand

filelist = FileItemize("\\Server\Public\FileAppendTest\*.txt")
For x = 1 to Itemcount( filelist, @tab)
    file = ItemExtract( x, filelist, @tab )
    ErrorMode(@off)
    ret =  FileOpen( file, "READ" )
    ErrorMode(@cancel)
    if ret == 0
     Pause("Uh oh! File is Un-readable...", file)
     Exit
   endif
Next

[morenos1]

Testing with this script I get the error on the first TXT file. However, I can open that same file with any text editor .....

[Deana]

Testing with this script I get the error on the first TXT file. However, I can open that same file with any text editor .....

Okay so maybe we are getting somewhere. Please provide answers to all of the following:

Are you logged in to a standard user account?
Does this user account have read/write access to that remote share?
Can you please remove ErrorMode from around the FileOpen and run the script again with DebugTrace enabled.

Code (winbatch) Select Expand

DebugTrace(@on,"trace-fileopen.txt")
filelist = FileItemize("\\server\share\*.txt")
For x = 1 to Itemcount( filelist, @tab)
    file = ItemExtract( x, filelist, @tab )
    ret =  FileOpen( file, "READ" )   
    if ret == 0
     Pause("Uh oh! File is Un-readable...", file)
     Exit
   endif
Next


Post the resulting trace-fileopen.txt and answers to the questions above.

[morenos1]

I am a "local administrator" account.

I have full rights to the share. I can create/change/delete anything from that share.

[Deana]

Strange, the wwwbatch.ini stuff is missing from the end of the trace file...Did you happen to remove it?

In the previous script, I forgot to add the DirChange to the remote share. That could be causing the FileOpen Error. ( However, I wonder why the extended error information is not getting written to the trace file. )

Anyhow, Please try running this code:

Code (winbatch) Select Expand


;test.wbt
DebugTrace(@on,"trace-fileopen2.txt")
DirChange("\\server\share\")  ;!!!!!!!!!!!!!!!!!!!!! MODIFY TO FIT YOUR NEEDS !!!!!!!!!!!!!!!!!!!!!!!!!
filelist = FileItemize("*.txt")
For x = 1 to Itemcount( filelist, @tab)
    file = ItemExtract( x, filelist, @tab )
    handle =  FileOpen( file, "READ" )   
    line = FileRead(handle)
    FileClose(handle)
Next
;Now try to write a dummy file to the remote share
handle = FileOpen("_DELETEME.TXT","WRITE")
FileWrite(handle, "TEST")
FileClose(handle)
FileDelete("_DELETEME.TXT")


Post  UNMODIFIED trace-fileopen2.txt.

Thanks in advance.

[Deana]

In addition, upon the 1077 error I would expect the error dialog to have a More Error Info button. Click it and post exactly what you see displayed.