none
Windows Explorer Properties Information Incorrect after 1803 Feature Update

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

    RBackupSets

      RProject_10

        Backup Set 2018-05-19 232221

          E

            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,

    Tao


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

    Monday, May 28, 2018 2:04 AM
    Moderator
  • 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
  • I submitted this problem about three months ago both here on TechNet and also via Windows 10 Feedback.  Others have submitted a similar problem summary way before I did.  Still no response to anyone as to a fix.  I did receive some comments from another individual that was tracking the same problem.  He stated that he had talked directly to a Microsoft support person who told him that the current Microsoft position on this is that we all have an install problem with the 1803 Feature update.  A total BS response from Microsoft.  if they would actually read the problem description and comments that line of thought would be quickly shot down.  So based upon their current thought pattern, no one should hold their breath waiting for a fix from Microsoft for this.  Apparently, based upon the comments that were passed to me, they don't think it is their problem.  Unbelievable!!  
    Saturday, August 18, 2018 11:44 PM
  • 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