Windows Explorer Properties Information Incorrect after 1803 Feature Update RRS feed

  • Question

  • I have encountered a number of directories that now show incorrect “properties” information after the recent Windows 10 upgrade to the 1803 Feature Update.  Most directories that I have looked at still show valid information.  But in some specific directories the calculated size, number of files, and number of folders is wildly inaccurate.  Prior to the 1803 update, the information appeared to be valid for these directories that are now in question.

    From one of these subdirectories, the “CNT +” subdirectory should include everything below it.  By just taking a brief look at the immediate subdirectories it can easily be seen that they describe more utilized space, number of files, and folders than indicated in the “CNT +” subdirectory itself.  In actuality, there are approximately 31K files, 4.5K folders, and a size of about 4.1G in total for the “CNT +” subdirectory where the current properties information shows just 87.2M for size with 695 files and 95 folders.  The directory structure and expected files are physically present.  I have walked the subdirectory structure and can see the expected components.

    For some unexplainable reason, a large number of these files are not being counted anymore in the higher level subdirectories.  It is not until you get deep into the subdirectory structure that the properties information becomes credible again.  It just looks like in some of the subdirectories that a large number of files and folders are being ignored.  I still haven’t been able to figure out why.  This has nothing to do with “hidden” files or other system related file information.  These are just plain user files.

    The subdirectories in question have been in the same structure and naming convention for years.  And I regularly used the associated properties information to verify the current backup size.  That is now failing miserably. 

    Thursday, May 24, 2018 8:24 PM

All replies

  • After some further attempts at problem determination, I decided to move the “CNT +” subdirectory in question to remove it from its higher level directory levels.  The higher level subdirectory names were added by the backup utility just for identification purposes and do not contain any files.  The “CNT +” directory is now a stand-alone directory on the same “F” drive.  The properties information now shows all of the expected size, files, and folder counts.

    Where the previous information under the normal directory structure displayed a size of 87.2 M with 695 files and 95 folders, as a stand-alone directory the properties information now displays a size of 3.15 G with 35,773 files and 4,543 folders.  These are the expected counts.

    The conclusion here is that some inadvertent limitation based upon subdirectory structure has now been encountered.  Prior to the 1803 Feature Update I did not see this occur.  There is nothing wrong with the actual contents of the file directory and its components.  There is a problem with the current method being used to calculate the “properties” information.

    The normal directory structure on hard drive "F" was --



        Backup Set 2018-05-19 232221


            Business Info

              CNT +

                (Following subdirectories)

    Friday, May 25, 2018 12:45 PM
  • Hi,

    Considering the Update is released recently, if the issue persists, you could try the built-in "Feedback" tool to submit the issue on your side.

    Thank you for understanding.

    Best Regards,


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

    Monday, May 28, 2018 2:04 AM
  • Tao,

    I had recently found the "Feedback" info for Windows 10 and have logged this information and detailed supporting documentation under the "Files, Folders, and Online Storage" category.  Now waiting to see if any further follow-up comes from the appropriate support group.

    Thanks for your follow-up response for this.

    Monday, May 28, 2018 1:51 PM
  • This has been reported for a few weeks now by myself and others.  The bug exists in all versions of Windows 10 from 1803 on to the RS5 beta releases.  There appears to have been no official response from MS to any of those feedback reports.

    The bug itself appears to be an issue of the total path length, not the number or nature of subdirectories.  But, of course, the more subdirectories one has, the more likely it is to have a long pathname to encounter this bug. 

    Disabling or enabling long filename support does not affect this behavior.

    Thursday, May 31, 2018 3:27 AM
  • Hey Grant,

    OK, thanks for your related comments.  I had come to a similar conclusion as to a probable cause based upon moving the subdirectory to remove the top three levels.  The result was accurate properties info.  So it was looking to me like a potential total path length issue but not much way to be able to completely prove that.

    I did notice a few other somewhat similar problem reports in the "Feedback" reports when I filed my report and supporting documentation about this problem.  I was glad to see that others had been reporting something that seemed quite similar.

    Now if MS will only wake up and address it. 

    Thursday, May 31, 2018 8:58 PM
  • Just installed the recently released cumulative update for Windows 10 at 1805 - KB4100403.  Same problem still exists.
    Friday, June 1, 2018 1:56 PM
  • Does this also affect any scripting that would be ran from the root of the drive and use a path of that same length?

    from an "f:\" prompt can you do a simple dir of this directory?

    something like this:

    dir "RBackupSets\RProject_10\Backup Set 2018-05-19 232221\E\Business Info\CNT +"

    "The only problem with troubleshooting is that sometimes trouble shoots back." "Network design is just like a stroll in the park. Jurassic Park, that is."

    Friday, June 1, 2018 8:33 PM
  • I tried a few tests with the "dir" command.  Running the command as specified only listed the specific files and directories in the "CNT +" subdirectory.  That information was correct as displayed.

    I then added the "/s" operand and piped the displayed information into "more".  I didn't go through the entire set of directories (There are about 35K files involved) but the "dir" command did appear to be walking through expected subdirectories and displaying the right contents for each. 

    Saturday, June 2, 2018 1:26 PM
  • Just installed the recently released cumulative update for Windows 10 at 1803 - KB4284835.  Same problem still exists.

    This problem has been reported via Microsoft Feedback for Windows 10 by me and others.  Microsoft Support apparently doesn't read that information either.  No response and the problem still exists.

    Wednesday, June 13, 2018 11:28 PM
  • I have a same problem with windows 10 new build 1803, property is showing less files and size than actual.
    • Edited by D Tun Sunday, June 17, 2018 2:40 AM
    Sunday, June 17, 2018 2:39 AM
  • I am having the SAME exact problem. Just started happening with 1803. This is really irritating.
    Saturday, July 7, 2018 12:01 AM
  • Is there a workaround for this? I am needing to ensure I have everything in order before I migrate cloud providers....funny that I'm migrating to Microsoft from Amazon because the Amazon Drive client was buggy AF. Looks like glitches are unavoidable...
    Friday, July 20, 2018 4:48 PM
  • I'm having the same problem in 1803. Seeing it in a folder on my desktop. Drive is Samsung 970 Pro SSD. 

    The folder "!inbox" is reporting 379 files, 43 folders. When I open the folder and check the first subfolder, "!!C DRIVE", the value is 379 files, 34 folders. When I select all the subfolders (the peers of "!!C DRIVE"), the result is 29,377 files, 3,699 folders.

    Based on this example, it seems like the enumeration for the "!inbox" folder is throwing a hidden exception or erroring out in the enumeration of the first subfolder.

    This is a dangerous issue. I'm just wondering how it slipped past QA.

    Friday, July 20, 2018 8:31 PM
  • I'm having the same problem, and also in the midst of migrating a client. I was wondering why the folder size was so inconsistent. Initially with SharePoint, when files were uploaded, the size of Office documents was changing, but discovered that is by design. And now after moving files from a Win8.1 machines to an external drive, then connecting the external drive to a Win10 (with 1803 update), folder sizes mismatched. I thought I'd been up for too many hours straight!

    The only way I can verify the number of files and total file size is running a "dir /s /a" which will give you a total number of files in that folder as well as sub-folders. The "/a" will include files that have attributes set, e.g. hidden files.

    Hope this issue gets resolved soon Microsoft!

    Sunday, July 22, 2018 12:54 AM
  • Other posts confirm that this appears to be a long path issue. 

    Why this matters:

    1. 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.

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

    Wednesday, July 25, 2018 6:58 PM
  • I still have this problem with 1803 with cumulative level KB4340917.  It has happened since implementing 1803.  When copying a large directory structure is is impossible to tell a successful copy when looking at the Properties. 
    Saturday, August 4, 2018 2:06 AM
  • You can solve this problem by decreasing the length of all the disk paths.
    For me I worked hard for 220.
    Use the soft like Long Filename Finder or Long Path Tool 5 or Too Long Paths Detector
    Sunday, August 12, 2018 11:31 AM
  • this works, but I am hopeful that there is an easier "fix" in the collective mind of MS--I do NOT want to contemplate doing this for ALL my files. One other observation from a non-tech person--the issue does not apparently exist on "old" folders, but I have not checked everything--it appeared for me on new files/new hard drives.
    Monday, August 13, 2018 4:14 PM
  • I have a Windows 10 Pro that I bought from Microsoft Store. It is updated to Version 1803 Installed 10-May-18 OS build 17134.191.

    On one of my my HD I have a Main Folder with subfolders. File Explorer reports the size of this Main Folder size as 4.96 GB, 528 Files, 77 Folders, where as it reports one of the subfolder size as 108 GB 1,030 Files, 74 Folders.!!! I do know from another software (TreeSize Free) that the actual size of the Main Folder is 574GB and 54,681 Files). This is unacceptable. How come TreeSize can get it right but File Explorer cannot?? I know you are having issues with File explorer, but when will this issue be resolved?

    Saturday, August 18, 2018 9:17 AM
  • Sent feedback, but unfortunately it is just being ignored. Please everyone make  enough noise so something gets done.
    Sunday, August 26, 2018 7:47 AM
  • I don't believe the issue is with long file names. The problem came about with the 1803 release. This problem did not exist before that.
    Sunday, August 26, 2018 7:51 AM
  • It is unlikely a long filename. The problem was not there before 1803 update.
    Sunday, August 26, 2018 7:58 AM
  • It is not an issue with new files. The problem is there for old files and folders. The problem came with update 1803
    Sunday, August 26, 2018 8:01 AM
  • I also had a chat session with one of Microsofts so called "Technicians" and been told that there is no issue with File Explorer. Strange that there was no problem before the 1803 update! Based on their attitude, I don't hold out much hope for a quick fix. I am using TreeSizeFree and it works fine, but why can TreeSizeFree give the correct answer where File Explorer cannot?
    Sunday, August 26, 2018 8:09 AM
  • exactly same problem on windows 10... i was exporting several thousands files to disk into a directory like 'C:\tmp\testexport\2018-09-06-1808\7bb55a1d-3421-4880-8ce1-04ceba06012f\dir1' and properties have reported around 1000 files and 122 directories, when in fact there was over  8000 files and 590 directories. When I moved 'dir1' folder one level higher, properties reported correct counts...

    i wonder if it's really the time to give linux a shot one more time... : )

    p.s. as i am posting this, i am getting "Unexpected error" when i press submit.. omg omg omg////

    Friday, September 7, 2018 7:09 AM
  • I also report this issue. I've been confused for a long time -- trying to back up to a USB drive and finding that my 250 G of data won't fit on my 1 TB USB-drive.  I finally realized that WIN was miss-reporting my directory sizes on my internal drive.  They report fine on the USB-backup. Other utilities always give the correct totals.
    Saturday, October 13, 2018 8:25 PM
  • Used PathLengthChecker and discovered a photo named with a 22 word sentence created a path length of 271.  The second longest path in this directory was 241. With this photo within the Parent directory, Windows properties reported the parent folder contained 44,743 files & 4813 folders occupying 13.3 GB. 

    Using the Everything search app, I could see there were 164,633 objects (files & folders).  I removed the photo from the directory and repeated the Windows properties query.  Windows now reported 151,879 files & 12,753 folders totalling 164,632 (one less than that reported by Everything) and occupying 64.4 GB of drive space.  

    Seems removing the long file path solved the issue; returning it to the directory tree resulted in only 44,743 files reported in Windows properties.  Window 10 Pro 64-bit build 1803.

    Tuesday, October 23, 2018 6:52 PM
  • Just an FYI

    Have been having these same issues since everyone else has, way back in May + -.

    Just noticed that issue is resolved on one of my computers 100%, all property numbers are back to normal on all folders, this just happened since my last back up last week.

    My other computer (#2) still has the issue. Thought it might have been the last Windows update but did that update on #2 and no resolve...

    Go figure??? 

    Sunday, October 28, 2018 8:32 PM
  • Just to add that I'm seeing incorrect no. of files and size of folder using 'Properties' in Windows version 1809

    now as well. I'll report this on the Feedback Hub.



    Friday, November 23, 2018 12:31 AM
  • YES, this is a problem, but I did not realize how serious until you explained "Scenario 1".

    Yikes, now I am worried. How can MS not fix this yet?

    Tuesday, December 4, 2018 5:48 PM
  • Same problem here. The guess that it's due to path length is consistent with my experience.

    I am trying to sync folders across multiple computers and I spent two days thinking the sync was not working. My original folder has 4 GB of data but the synced folder only reports 800 MB. 

    The original folder is a root directory in my F drive

    The synced folder is nested in Documents. 

    Without a third party app like TreeSize I'd have no idea if my files were being properly backed up. This is really terrible coding from Microsoft. An unacceptable bug. Managing files is the heart of what an OS is for.

    Monday, December 17, 2018 11:39 PM
  • Same problem here

    properties display            9 890 files        909 dirs   20.7 Go

    simple python prog  2 422 661 files   76 788  dirs  882.7 Go

    robocopy                  2 422 657  files  76 789   dirs  878.952 Go
    • Edited by manu9257 Friday, December 21, 2018 1:34 AM
    Friday, December 21, 2018 1:29 AM
  • I also have this issue logged via the Windows 10 Feedback support method and it has been there since May along with a number of others that have described this problem.  I just checked it to see if any status has been posted and finally Microsoft formally responded.  Their response indicated that this will be fixed at an upcoming build 18298+.  At least some recognition of the problem from Microsoft where it has only been denial of any problem up to this point.  Hopefully this might actually get fixed in the near term!!!    
    Monday, December 24, 2018 7:30 PM

    Friday, December 28, 2018 4:58 AM
  • That would be good. I'm currently trying to rebuild all my storage, which involves moving more than 5TB from an old Drobo onto a new WD PR4100. So far, Windows Explorer reports properties discrepancies between original and copy on many folders. I want to wipe and format the Drobo but daren't until I know the data has copied safely. FreeFileSync says it has but I'd really like Windows to agree.
    Saturday, December 29, 2018 2:24 PM
  • I noticed that I have a July 30, 2017 file backup performed using Windows Explorer file copy (drag and drop) whose properties also display the same type of incorrect information (smaller size, number of files, and number of folders). This would indicate to me that the issue may have existed in versions earlier than 1803.

    Wednesday, January 16, 2019 9:47 PM
  • Ok, Bill, time to get back to coding. Remember how fun it was staying up all night? Forget all that humanitarian stuff for now.

    Jack Ritter

    Tuesday, February 5, 2019 5:33 PM
  • Yesterday I just picked up and installed the re-released 1809 Feature Update (Build 17763).  Just taking a shot to see if it might have addressed the current Properties information problem.  Unfortunately no, the reported Properties information is still bad related to the cases that have been reported by many people besides myself.

    So, as indicated in my previous update from December, according to Microsoft support this will be fixed with the upcoming 18298+ build.  From what I see in currently published information, that build level will be associated with the planned 1903 Feature Update.  

    Bottom line here is that we are still waiting for a formal fix to this problem that was induced by the 1803 Feature Update from Spring of last year. 

    Thursday, February 7, 2019 1:51 PM
  • I am on Version 10.0.171134

    My File Explorer Count is Incorrect with Windows 10 Pro

    Windows 10 Pro Says 173K + Files the Real count is 209K +  

    The way that I have Confirmed this 

    Server 2012R2  Counts the Files as 209K +  Down to The File 

    Qnap File Station counts The files as 209k +   Down to the file

    Windows 7 Pro Counts  the Files As 209K  +    Down to the file 

    I  thought I had been hacked or sometime bad. MS get your act together

    I can only Conclude Windows 10 Pro is the problems

    If you want to Count your files try what I did.  

    Anyone please respond to my request


    Thursday, February 21, 2019 7:07 PM
  • I made Mistake Window Pro 7 Counts as 173K+ 
    Thursday, February 21, 2019 7:09 PM
  • Same problem here, even with latest Win10 update. File size and number are reported (hugely) incorrect.
    Tuesday, February 26, 2019 9:02 AM
  • Same problem here, build 1809. And it's off by a huge margin. Really annoying btw lost a day troubleshooting why I was getting what I thought were duplicates in a azure blob storage upload. Not until I did a powershell command get-childitem -recurse | measure on the local file system did I figure out what was going on.
    Tuesday, February 26, 2019 9:53 PM
  • The problem still exists as of today. I bought a new Western Digital 4TB My Passport HD recently. I created a new folder named "Backup1" inside it.

    After I transfer files from my old WD 4TB My Book HD, to the new Passport HD, I noticed when I view the properties of the "Backup1" folder, several thousand files were not counted, as compared to my old Book HD.

    I thought I had a faulty new HD, ran the WinMerge program, that compare the number of files between the new & old HD, it says both are identical. Luckily I found this forum thread, learned the problem was there were too many subfolders. After I proceed to move my copied files & folders out of "Backup1" folder, the files were once again counted correctly. I wonder when is this bug going to get fixed.  

    Saturday, May 11, 2019 2:27 PM
  • Exactly same problem here, with a 1809 release...
    Monday, May 13, 2019 1:41 PM
  • Today, after updating Windows 10 Pro from version 1803 to version 1903, File Explorer now seems to correctly count folders and files (and their sizes).  

    Apparently fixed on my computer is a problem where File Explorer had been incorrectly reporting properties of folders that had been backed up from internal hard disk drive to external portable disk. 

    Thanks, Microsoft.

    Monday, June 3, 2019 11:38 PM
  • I recently upgraded to the newly released 1903 Feature Update (Build 18362) and the reported file counting problem associated with the Properties information appears to now be corrected.  I have reviewed a number of file directories that I know were displaying incorrect information and that information now appears to be correct and usable again.
    • Proposed as answer by EckiS Wednesday, June 12, 2019 7:35 PM
    Wednesday, June 12, 2019 7:01 PM
  • I too upgraded to the 1903 Feature Update (Build 18362.175), and the File Explorer still has incorrect information unless I go deep into the file structure I've been using for years. I have terabytes of videos and still photos with well over 400,000 files from photo archives and projects. 
    Sunday, July 7, 2019 10:09 PM