none
Incorrect folder sizes reported in build 17134.1 RRS feed

  • Question

  • Hi,

    After receiving the final release of build 17134.1 I have noticed that the size of folders on both of my drives are less than the actual size inside.

    I had this issue before when I tried the insider build of this version, but reverted back to the previous version as this is a fairly big bug for me, and assumed it would be fixed/ noticed by the time of public release. When reverting back to the previous version, the folder size returned to normal.

    I'm thinking it's a bug with the calculation of the size as when deleting a folder, the true size is noticed (e.g. removing 100GBs of data), yet when navigating to the folder's properties the size is calculated wrongly (e.g. only 60GBs)

    Sorry for the lack of technical information,

    aTOM19

    Thursday, May 3, 2018 6:25 PM

Answers

  • I have the same problem, and have narrowed it down to Windows 10 not including all of the files when it calculates the folder size. The underlying cause appears to be that files in deep subfolders are disregarded, even if the long filenames feature is enabled in the registry. I noticed that if I shortened the names of some of the folders, more files would be included in the calculations.

    The files are all there, and can be opened as usual. I've used other utilities to try and establish if anything might be wrong. WinDirStat does give the right folder size, as well as the right number of files. GoodSync sees all of the files, too.

    EDIT 1: in my case, the problem started shortly after a clean install of April update. I don't think it began straight away, but I cannot be sure.

    EDIT 2: I resolved the issue by scanning for files over 255 characters in length using the TLPD utility and then renaming them. After I'd done that Windows Explorer correctly stated the size and file count for the main folder. Interestingly, it was off by thousands of files before I did this (!) even though only 7 files had names that were too long.
    • Edited by B_Maior Friday, May 4, 2018 10:59 PM
    • Proposed as answer by hm vdbm Saturday, June 16, 2018 7:45 AM
    • Marked as answer by atomc19 Saturday, July 7, 2018 1:46 PM
    Friday, May 4, 2018 4:21 PM

All replies

  • I noticed that the problem happened before you upgrade to 1803.So which version did the problem be fixed and which version did the problem exists?

    The incorrect folder size may be related to what you delete.

    It is suggested that you can Uncheck the option "hide protected operating system files" in file explorer option and seen if there is any hidden files generated. 

    You can use dir /a/s command to view every file, including system and hidden files. This will give you total size you desire.

    Are there any symptoms that indicated the wrong folder size?


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Friday, May 4, 2018 4:58 AM
  • I have the same problem, and have narrowed it down to Windows 10 not including all of the files when it calculates the folder size. The underlying cause appears to be that files in deep subfolders are disregarded, even if the long filenames feature is enabled in the registry. I noticed that if I shortened the names of some of the folders, more files would be included in the calculations.

    The files are all there, and can be opened as usual. I've used other utilities to try and establish if anything might be wrong. WinDirStat does give the right folder size, as well as the right number of files. GoodSync sees all of the files, too.

    EDIT 1: in my case, the problem started shortly after a clean install of April update. I don't think it began straight away, but I cannot be sure.

    EDIT 2: I resolved the issue by scanning for files over 255 characters in length using the TLPD utility and then renaming them. After I'd done that Windows Explorer correctly stated the size and file count for the main folder. Interestingly, it was off by thousands of files before I did this (!) even though only 7 files had names that were too long.
    • Edited by B_Maior Friday, May 4, 2018 10:59 PM
    • Proposed as answer by hm vdbm Saturday, June 16, 2018 7:45 AM
    • Marked as answer by atomc19 Saturday, July 7, 2018 1:46 PM
    Friday, May 4, 2018 4:21 PM
  • I am experiencing the same problem with many folders. With same version on windows if you try Treessizepro it  provide correct folder size so I assume is a problem may lay with explorer.

    One of the most incredible Microsoft BUG of last 10 years !

    Ciao

    • Proposed as answer by AedesVexans Tuesday, July 24, 2018 12:06 AM
    Friday, June 15, 2018 8:35 AM
  • I experienced the same problem. I'm working with Windows 10 Home  64b, version 1803, installed on 23/05/2018,  OS build 17134.48.  Exact timing is difficult, but I can be certain that this problem did not occur before may 2018 (although the same too long filenames existed already).  THE TLPD PROCEDURE SOLVED THE PROBLEM, thank you Mr. Maior !

    Same observation : size & file count for the main folder were off by thousands and yet the tlpd yielded only ± 20 too long filenames.   IMPORTANT : I had to run tlpd twice to resolve the problem. Strangely, adaptations after the first run did not solve the problem and a second run showed some too long pathnames that were not detected with the first run. 

    Curious and eventually useful : right number of files and right folder size are still shown in Windows File Explorer when copying the folder :  in the file copy dialog the numbers of items remaining (to be copied) seem to be right.

    Saturday, June 16, 2018 7:46 AM
  • I have a same problem with windows 10 new build 1803, property is showing less files and size than actual. Looks like problem is with folder property calculation in new spring update.
    Sunday, June 17, 2018 2:43 AM
  • I can confirm the issue via Windows 10 Enterprise 64-bit (Version 1803, Build 17134.137).

    I only noticed the problem on mirroring a (data; very few hidden files) drive to ext4; total size being off by several hundred GBs.

    The drive recently was checked by windows board tools; data on it also isn't new, just gradual additions. Explorer was restarted multiple times, yet insists on showing incorrect totals (subfolder; drive). This simply is unacceptable!

    Windirstat (non-admin mode) listing correct values. I shall investigate possible workarounds for the time being, thanks guys!

    p.s. Doesn't look like length issue here on first glance.

    // Correction: Checked via TLPD and I have couple files near breaking point exceeding 255 chars. "LongPathsEnabled" via registry was set already.

    Unicode?

    // Notes:

    Files are not discovered by explorer, i.e. count is incorrect. See here: https://borncity.com/win/2018/05/04/windows-10-april-update-bugs-and-issues/ "Explorer bug: file enumerations"








    Thursday, July 5, 2018 8:05 PM
  • I've got the same issue here, only it is a fresh install of 1803 and it is reading *more* than the folder holds.

    If I click on the user name, click properties, it shows 389GB of data (only 66GB of data on the entire drive). If I go one step deeper and click on all of the user data it will show 3.75GB of data. If I click on the pictures folder alone (which is included in the previous grouping) it will show 7.5GB of data.
    Monday, July 23, 2018 7:14 PM
  • This is clearly a bug. I am back from a 25 year hiatus.

    Microsoft needs to heed my warning. We have a lot to discuss.

    aka.. mtn287

    Wednesday, July 25, 2018 12:22 AM
  • The potential for loss of data seems very real. One scenario: a folder containing a set of nested folders forming a long path that breaks folder properties, with no files in any of the folders. This top-level subfolder is followed by other subfolders with thousands of files. Folder properties would show 0 files thanks to this bug. User shift-deletes the root folder thinking it's safe and watches in horror as their data is purged.

    Browsers and modern dev tools like npm create these paths all the time. This is not rare or unusual.

    • Proposed as answer by Gianni1962 Wednesday, July 25, 2018 11:51 PM
    Wednesday, July 25, 2018 6:59 PM
  • Thanks for helping maintain my sanity. When I reload PCs, I grab the entire profiles (less some unneeded and temp files I delete through a script) and save them to a network share. When I restore the data back to the users's PC, I compare the size of both directories to make sure everything was there. I couldn't for the life of me figure out what the issue was.

    I will try tlpd, hoping it won't cause any issues with the data being restored, but I hope they come up with a fix for this.

    www.sflesch.com

    Wednesday, August 22, 2018 3:55 PM
  • I have same problem with--> OS build- 17134.228, Edition- Windows 10 Pro, Version- 1803

    Incorrect folder size is not related to delete or anything. It's just simple on laptop hard drive and also on external hard drive that I have been using it since age. Folder property always shows less amount of size than actual size inside the folder.

    Thanks,


    • Edited by MP1_JS Thursday, August 23, 2018 7:50 PM
    Thursday, August 23, 2018 7:49 PM
  • Facing the same issue, Version 1803, OS build 17134.254 Win 10 Pro. The issue still persists. But apparently, this triggers only on my external hard drive (WD passport) as far as I have witnessed. At the moment to really compare the sizes of copied folders and files, I use a third party software. In case, anyone want to know the name of it (WinDirStat), till windows fixes this CRITICAL issue.
    Thursday, September 6, 2018 9:51 PM
  • Problem definitely related to path length. Seems like the tool that scans for a folder's content size just terminates once it hits the first file with path length beyond MAX_PATH.

    Crucial that this problem gets fixed! High risk of data loss.

    Saturday, September 29, 2018 6:27 PM
  • Hi,

    I have the exact same problem. 

    Does anyone knows when this bug will be fixed?

    Friday, October 5, 2018 8:45 AM
  • Just a thought: perhaps this is related to the data loss scandal currently going on in build 1809?
    Anyway the issue still isn't fixed! And I doubt it will be anytime soon unless enough of a fuss is made :(
    Saturday, October 6, 2018 8:30 PM
  • Just to add to this, I can also confirm that this is still easily reproducible on 17763.1.

    Tuesday, October 9, 2018 11:33 AM
  • And still broken in the re-released 17763. Folder information is still incorrect in 17763.134.
    Friday, November 16, 2018 11:14 AM
  • Confirmed issue is present in Windows Server 2019 (version 1809), build 17763.107.
    Tuesday, November 20, 2018 2:38 PM
  • i just got this bug

    only on one folder !

    win 10 enterprise v1809 build 17763.253

    :(

    Wednesday, January 23, 2019 12:35 AM
  • Same issue exists on same build #s of Win Server 2019...very big concern after a mirroring job - good thing the 3rd party tool verified the data & files are actually there. Who would think going from w2012-w2016 would take a step back over a decade in file browsers/management.
    • Edited by nj12nets Monday, April 8, 2019 8:09 PM
    Monday, April 8, 2019 8:08 PM
  • Also all the way up to 17763.374 as of now it still it F*d up.

    Friday, April 19, 2019 9:53 PM
  • Also having same problem on a Brand new Dell Server with 2019 Server Standard pre-installed - all updates installed and the info is not even close. I get the correct info when I look at the share from and Older OS like Windows Server 2008 R2 but when looking on that actual machine where the data is housed the info is bogus on any folder that has any deeper sub folders in it. 

    Rich

    Saturday, May 4, 2019 1:40 AM
  • Hello,

    Has anybody tried this with 1903 to see if the issue still occurs?

    Have you all filed feedback with the Feedback hub or opened support cases to report this?


    Thanks, Darrell Gorter [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.

    Saturday, May 4, 2019 7:10 PM
  • is there any sulution for this problem?
    Tuesday, May 28, 2019 4:44 PM
  • Hello,

    This should be fixed in 1903, if you are seeing this on prior versions please file bugs via Feedback Hub.


    Thanks, Darrell Gorter [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.

    Wednesday, May 29, 2019 11:00 PM
  • Hi Darell, 

    This is fixed on Windows 10 1903 - but what about Server 2019 ? I have it installed with patches up to August 2019 and it is still producing the incorrect paths. As specified above, this causes issues that people think certain folders are safe to move/copy/delete but the actual data is very different from what is shown in the folder properties.

    I have even rolled back a server to Windows 2016 because of this issue.

    Thursday, September 19, 2019 8:30 AM
  • Hello,

    Checking on Windows Server 2019.


    Thanks, Darrell Gorter [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.

    Saturday, September 21, 2019 3:05 PM
  • Hello,

    This should have been addressed have you tried enablinh Long Paths.

    from this document link:

    https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file#maximum-path-length-limitationto

    Enable Long Paths in Windows 10, Version 1607, and Later

    Starting in Windows 10, version 1607, MAX_PATH limitations have been removed from common Win32 file and directory functions. However, you must opt-in to the new behavior.

    To enable the new long path behavior, both of the following conditions must be met:

    • The registry key HKLM\SYSTEM\CurrentControlSet\Control\FileSystem LongPathsEnabled (Type: REG_DWORD) must exist and be set to 1. The key's value will be cached by the system (per process) after the first call to an affected Win32 file or directory function (see below for the list of functions). The registry key will not be reloaded during the lifetime of the process. In order for all apps on the system to recognize the value of the key, a reboot might be required because some processes may have started before the key was set.

      Note

      This registry key can also be controlled via Group Policy at Computer Configuration > Administrative Templates > System > Filesystem > Enable NTFS long paths.


    Thanks, Darrell Gorter [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.

    Monday, September 23, 2019 3:27 PM
  • I have the same issue with Windows Server 2019 1809. I have set the LongPathsEnabled registry key, rebooted and the issue is still there.
    Tuesday, September 24, 2019 4:14 AM
  • This was also the registry key that I tried in Windows 10 1809 and that also didn't fix it. It works in Windows 10 1903 without any issues.

    I have tried the registry key on the Windows 2019 server and problem is still the same after reboot.

    Tuesday, September 24, 2019 6:08 AM
  • I believe this may have been resolved with KB4516077.

    https://support.microsoft.com/en-us/help/4516077/windows-10-update-kb4516077

    Improvements and fixes:

    Addresses an issue that causes File Explorer to report the number or the size of files and folders incorrectly when they use long paths.


    • Edited by RLC1234 Tuesday, October 1, 2019 1:05 AM
    Tuesday, October 1, 2019 1:04 AM

  • Finally a fix that works... Thanks RLC1234.

    Why did it take soooo long to fix...


    Wednesday, October 2, 2019 10:55 AM