Windows File Explorer Not Showing Correct Folder Size If Folder Named 'Applications'

Anonymous
2018-05-03T21:08:26+00:00

Since installing the 1803 update, Windows File Explorer doesn't display the correct folder size if the folder is named 'Applications'.

There seems to be a bug that if the folder name is 6 characters or more and starts with 'Appli', the folder size shows significantly less than it actually is.  For example if the folder is named 'Apps' or 'Appli', it will display the size correctly.  If however it is named 'Applications' or 'Applix' or 'Appliy', then it won't display correctly.

The Feedback app doesn't work on my computer due to having telemetry settings set to 'Basic', therefore I am reporting the bug here instead.

OS Version:

Windows 10 Pro X64 (17134.1, 1803)

Screenshots:

Windows for home | Windows 10 | Files, folders, and storage

Locked Question. This question was migrated from the Microsoft Support Community. You can vote on whether it's helpful, but you can't add comments or replies or follow the question.

0 comments

102 answers

Sort by: Newest
Most helpful Newest Oldest
  1. Anonymous
    2019-05-22T00:39:04+00:00

    i can say that the latest version of windows finally FIXED the issue (Windows 1903)

    Was this answer helpful?

    0 comments
  2. Anonymous
    2019-05-20T06:28:14+00:00

    I think this is the matching issue in the Feedback Hub.

    https://aka.ms/AA345sy

    They say it is fixed in build 18298, but I don't know why they wouldn't try  to fix it in a cumulative update for 1809 (which is build 17763).

    Was this answer helpful?

    0 comments
  3. Anonymous
    2019-05-18T00:46:24+00:00

    Dave (and Scott)

    Please make sure that they are aware  that this is not just a server problem.

    Most of the posts are from Windows 10 users, I seem to recall posting a few folder property screen grabs myself a half million pages back on this thread.

    In any case, it's very much appreciated that you have gotten their ear on this issue.

    Thanks,

    Kevin G

    Orange, Ct.

    Was this answer helpful?

    0 comments
  4. Anonymous
    2019-05-17T23:26:37+00:00

    Hi Scott, I have also been working with Microsoft (took a while to break through) and will share what they end up deciding on my case. Service Request: “SRX1471754629ID” please feel free to reference that if you think it will help. I’ll also post the results of my case. I have also been engaging some Microsoft techs in Denver and they are able to replicate the core issue for the software engineering group. Let’s hope they really do something!!

    Dave Chappell

    Was this answer helpful?

    0 comments
  5. Anonymous
    2019-05-17T20:40:19+00:00

    May 17 2019 just finding this issue during a server upgrade from Winserver 2008R2 to Winserver 2019 (fully updated to 1809 17763.503).

    I just spent the last 24 hours freaking out over this. NOT COOL!

    This is my third 2008R2 to 2019 upgrade / migration this year and I realize why I have not seen the problem until now.

    When you use the older 2008R2 machine to push (RoboCopy) the files to the new server they successfully copy. If you use the same 2008R2 machine to check the properties on your Source & Destination the copy shows as (bit for bit) perfect.

    BUT! If you use the 2008R2 machine to check the source, and then use the 2019 machine to check the Destination, that is where you see the huge discrepancy.

    With almost 1TB of data copied over, there is no way I can look through all the folders / files to see if there is anything missing.

    Microsoft needs to provide an explanation for this! Obviously many people are running into this issue and the questions are going unanswered.

    I will open up a case with Microsoft via my partner account and provide a link to this blog.

    I will post the outcome once I get an explanation from support.

    Was this answer helpful?

    0 comments