FileExist start to fail after latest patches

[allalevkov]

Hello,
Does anyone have the same problem with FileExist after MS patches installed?

I have a file transfer program which sleeps for 1 hr, then wakes up, checks directories and performs all transfers scheduled for the hour and goes to sleep for remainder of the time.  So, on the hourly check all directories give an error, even those on C-drive, after that they are OK because all the transfers work.

Originally the issue started after MS patch 1803 was installed, it was said to have issue with new cashing MS invented, it affected net share locations only.  I found registry fix for that and it worked for a while.  Now, with the next set of patches it started again, even with C-drive directories. 

I run WinBatch 32bit compiled on Win server 2012.   Would really appreciate any insight into this.
Thank you in advance,
Alla

[td]

No insights but what do you mean by "fail"?  What behavior are you seeing from the function that you thing means the function failing?

[allalevkov]

IT returns @false for perfectly existing directory, even on C-drive.  Should have been more clear on that.  There is no function error, just negative response.
Thank you for quick reply.

[kdmoyers]

If this were me, I'd be trying all sorts of different files on the C-drive, looking to see what works and what doesnt.

Does it work correctly on *any* files on the c-drive?  Can you see any patterns?

Does DirExist work on folders? is there any pattern there?

I guess the idea is, maybe add more and different tests, to see what works and what does not. 
By examining the boundary of failure, sometimes you find it's nature.

[td]

Our testing doesn't show the FileExist function has any issues accessing local files on Windows 2012 with the NTFS file system anyway.  As the OP may have been alluding to, there was a bug in Windows 2012's implementation of SMB that could cause file access problems because of system cashing.  Microsoft reportedly fixed this issue but I am not sure that they ever got it completely corrected.

It may be of some use to know if the OS is Windows 2012 or Windows 2012R2 and if the OS's file system is NTFS or not. 

[td]

Reading the original post again I noticed the mention of "MS patch 1803". The 1803 number suggests the problem appeared after Windows 10 feature update 1803 and may, therefore, be a Windows 10 issue and have nothing to do with Windows 2012.  Windows 10 feature updates are notorious for causing hardware issues.  We had to junk a workstation because the 1803 feature update was incompatible with the CPU/motherboard on the system even though the system was only a couple of years old at the time.   (The workstations manufacturer confirmed that this was the case.) 

The latest version of WinBatch is always tested on the latest version of Windows 10 widely available at the time of the WinBatch release so we know of no issues specifically related to WinBatch and the various Windows 10 feature versions.   Currently, WinBatch should be go-to-go on Windows  10 up to and including version 1903 (OS build 18362.449).

[allalevkov]

Thank you so much for all replies.  The registry fix was corrupted or removed by next patches (or someone else??).  The problem went away after registry was restored.  C-drive had other unrelated permission issues.  So double trouble...
Again, thank you very much and WinBatch is working great.
Alla