DirSize Max?

Started by seckner, June 23, 2017, 06:38:20 AM

Previous topic - Next topic

seckner

I have a directory which is huge. It's currently at 1.3 TB and growing (it's a user share dir but the program is running on that local server). Within the last few months as the directories have grown I'm seeing the DirSize function erroring out. Is there a practical size that too big for DirSize? It seemed to work at 1 TB to 1.1 TB but at 1.2, not so much. I found an article in the database that used a udfShellDirSize( directory ) function and that does work so I have a work around, I guess now I'm just curious.

td

There is no directory size limit for the DirSize function.  The purpose behind the udfShellDirSize UDF is to avoid a small representation error that can occur when having DirSize return a floating point value.   But since you did not provide any information about the version of Windows and WinBatch, and did not provide an error number, not much else can be said.
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

seckner

Sorry for the lack of info - It's running compiled on Server 2012 R2, Winbatch version is 2017B. It's not an actual Winbatch error, it's a windows error via popup that "RoboCopy_UserShares_x64.exe has stopped working. Do you want to debug or exit?" Exact same error on Windows 10 x64 ver 15063. The reported size of the directory is 1338706800640. The reason that I thought it might be the FileSize() function is because I walked the script with the debugger and it threw the error on that specific line after a few minutes of crunching the number. The line is Size = DirSize( PathFrom, 0, 1 ) - PathFrom is in the form of a network drive UNC (\\server\share)
   
Faulting application name: RoboCopy_UserShares_x64.exe, version: 1.9.0.0, time stamp: 0x58ed0beb
Faulting module name: ntdll.dll, version: 6.3.9600.18696, time stamp: 0x59153753
Exception code: 0xc0000374
Fault offset: 0x00000000000f1c00
Faulting process id: 0x2314
Faulting application start time: 0x01d2ebb7d939beef
Faulting application path: C:\Winbatch\Robocopy Nightly\RoboCopy_UserShares_x64.exe
Faulting module path: C:\Windows\SYSTEM32\ntdll.dll
Report Id: 1c2bc35e-57ab-11e7-8111-000af74e0ba6
Faulting package full name:
Faulting package-relative application ID:

td

That is a heap corruption error and it is occurring in a system DLL (ntdll.dll).  The problem is likely do to some combination of the size of the directory and the fact that it is a share but definitely does not have anything to do with some limit in the WinBatch function.   Without a full crash dump it is more less impossible to determine the exact source of the problem or who the guilty party might be.   Microsoft is constantly patching the Windows SMB protocol (share implememtation) because of bugs and security issues on newer versions of Windows.  So the problem could go away by itself after a few patch cycles. 
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade