After the 1607 Anniversary update many of my WinBatch scripts are broken from "file not found" when run on a network mounted drive. A simple demo script is attached. It gives the following output:
Windows 1511:
File open demo
Found file '\rad\winbatch\windowsUpdate.wbt': YES
Working dir: F:\rad\WinBatch\
Windows 1607:
File open demo
Found file '\rad\winbatch\windowsUpdate.wbt': NO
Working dir: \\10.10.1.6\production\rad\WinBatch\
F: is mapped to "\\10.10.1.6\production" so everything makes sense but it's hard to accept the fact that Microsoft suddenly decides to change the meaning of "root" folder without prior notice.
I have too many scripts referencing files this way so I'd like to know if there is a workaoround. Thanks!
******************************
WinBatch source:
workingdir = DirGet( )
fn = "\rad\winbatch\windowsUpdate.wbt"
if fileexist(fn)
fileFound="YES"
else
fileFound="NO"
endif
pause("File open demo", strCat("Found file '", fn,"': ", fileFound, @cr, "Working dir: ", workingdir))
I can only offer a few observations.
- WinBatch has been tested and used in-house on MSFT's Windows 10 Anniversary Update (version 1607) and no changes to WinBatch have been found to be necessary.
- A test script based on your example correctly reports existing files as existing when executed on Windows 10 version 1607.
- Based on reports Windows 10 version 1607 has had more than its share of issues with device drivers and hardware in general on some systems and not others.
- The version 1511 to version 1607 upgrade process has been reported to sometimes make seaming random and unexplainable changes to the upgraded systems.
You might want to reconsider your assumption that the problem is because of a change to the ' the meaning of "root" folder'. There are many potential causes of the behavior you are seeing with your script including changes to default permission and/or UAC and changes MFST may have made to the Windows implementation of the SMB protocol. A bit of investigation and testing may reveal what is actually going on.
I'm running WinBatch 2016B 32 bit.
The script is running fine when started in WinBatch Studio but gives error (using UNC path notation) as described above when I doubleclick .wbt file. This bug has been reported by other users as well:
https://social.technet.microsoft.com/Forums/en-US/97f7a09f-69b2-41be-9a51-209fe30a25fe/windows-1607-anniversary-update-broke-my-scripts-unc-paths?forum=win10itprogeneral
Are you able to run the demo script successfully in both modes?
Out of curiosity, and as you reported no issues, I installed WinBatch trial on another PC, 1607, 32 bit so should be identical to my own PC. On this second PC the script runs flawlessly. What is wrong with my PC?
Thank you.
Examining the UAC settings deeper I tried changing this value from 1 to 0:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\EnableLUA = 0
After reboot all is fine.
It should not necessary to turn off UAC to solve your problem and yes, we tested a script based on your description in both WBS debug and directly from a shell window. In both cases the script worked as expected. The WinBatch Studio debugger and WinBatch executed from a 'File Explorer' window use the identical WIL interpreter DLL. The only difference is that the debugger takes about twice as long to execute each line because it checks-in with the host process.
Windows 10 has had more than its share of bugs compared to previous versions of Windows and they have tended to not be universally reproducible. You have likely encountered one of them.
(FYI, it is necessary to map a drive from an elevated admin account in order for an elevated WinBatch process to 'see' the drive unless the system is configured to make mapped drives available to all users. See the Tech Database for details.)