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

102 answers

Sort by: Most helpful
  1. Anonymous
    2018-05-09T09:04:58+00:00

    I have almost the same problem, but it seems to have nothing to do with the file name. Since I upgraded my windows to 1803, my explorer behave weirdly in reading folder size.What it shows is different from the the real size of all files it contained.The difference could be so huge, for example, the folder size is read to be only 649 MB, but the actual files and folder it contained is 9,92 GB.

    Was this answer helpful?

    20+ people found this answer helpful.
    0 comments No comments
  2. Anonymous
    2018-07-18T23:07:28+00:00

    I'd guess it's related to path name length.

    Was this answer helpful?

    7 people found this answer helpful.
    0 comments No comments
  3. Anonymous
    2018-12-14T18:36:25+00:00

    I bought a brand new NAS Synology DS918+. I tried to copy all the data from my drive E: to that NAS.

    What a surprise when all was done, the Explorer said that on NAS is 222GB and on the E: is 277GB. Where is the 55Gigs? So it started. So many dirty words. So much wasted time. Here is what I found.

    If you don’t want to be sick don’t read this article, throw away your PC and move to some uninhabited island.

    The problem is in the Path length of Windows Explorer.

    Path Length = PL

    There are two different PL in an Explorer. "Directory PL" and "File PL"

    The "Directory PL" can not be longer than 247 characters.

    If you try to create or copy a Directory where the result Directory PL will be longer than this limit, the operation will be rejected and you will see warning "The Path is too long. Make it shorter".

    If you try to rename (prolong) the last Directory name it won't let you add a next character (no warning).

    If you try to rename (prolong) any Directory name within the tree, it lets you until you reach the limit on that particular name. Than it wont let you add next character. It means that in this case the PL is checked (counted) only from root to this Directory name. The Directory names behind are not counted

    BUT! (read later…)

    The "File PL" can not be longer than 259 characters.

    If you try to create or copy a File where the result File PL will be longer than this limit, there is no problem (strange!).

    If you try to rename (prolong, shorten or just change) the File name which is now and than longer than the limit, it won't let you save it and you will see warning "The File name is invalid or too long. Rename it".

    If you try to rename (shorten) the File name which is now longer but the result will be shorter than the limit, it works (of course).

    Why is the limit 12 characters longer? Probably because of the old DOS 8.3 convention. 8 characters name, one dot and 3 characters suffix, All together 12.

    The meaning is probably that if you have the full limit Directory PL you have still space for standard DOS File name.

    These are the limits of the „Explorer Editor“. The Properties have a little different limits.

    Now about the Properties.

    For the tests there is 9 Directories, 25 characters each and one with 10 characters, plus the E:\ (3 chars), plus the \ after every Directory. All together 247 characters (full Directory PL limit).

    In the last Directory is one file 1023 Bytes long.

    Here I made the tests.

    If we have the full Directory PL and one file which does or doesn’t exceed the File PL limit, we will see this:

    So far so good.

    Let‘s add one or two… or 8 characters into the Directory tree. And… nothing happened! The result will be the same.

    The limit of Directory PL for Properties is 255! (No it’s not! You’l see!) If we add 9 characters we are out of limit. But this means that the Editor limit was pushed by 9 characters and now we are unable to edit the name of the last Directory unless we short it by 9 characters. What a mess you think? Wait!

    Now let‘s see what happens if we cross the limit by one character…

    In the Properties window we see 3 nonsenses. 0 Files (one is there, obviously), 0 bytes (the File has 1023 bytes) and 257 Folders (WTF?).

    Even when I deleted the file it looks the same.

    What about the limit 255? Yes it is, but only in this exact example (one file in only one last Directory).

    If I add at the end some Directories of the same name length with the same File the limit shrinks.

    Let’s make 5 Directories with 5 Files and let’s see what happens.

     

    Here it is OK. The Directory PL is 250.

    Rise it to 251 and here is a mess again. It found only 2 Files from 5.

    I tried with 10 Directories/10 Files and the result is the same. Seems the real Directory PL limit is 250 (for Explorers Properties).

    So here are some rules for the Properties of Explorer:

    All the Files which are behind the 255 Directory PL limit are not found.

    Some Files which are behind the 250 Directory PL limit are not found (the exact rule is unknown).

    The lenght of the File name doesn’t matter (hopefully).

    It's sad that after 25 years of Windows on the market, the most fundamental function such as files and folders processing, does not work properly.

     Shame on you Microsoft.

    Was this answer helpful?

    6 people found this answer helpful.
    0 comments No comments
  4. Anonymous
    2018-07-05T22:31:58+00:00

    I replaced a customers laptop HDD today, was transferring back his data (100 gigs of photos and movies (.mov and ;jpg files)  I have 1803 on my PC where I had his data backup, I had installed 1709 on his laptop, which was downloading updates at the time of the transfer. My PC told me I was transferring 57 gigs of data, when I looked at the laptop after 3 minutes the progress bar told me I had 99 gigs remaining! 

    Imagine my surprise!

    I went back and checked, if I highlight all the individual files in a folder I get the correct size, If I ask for that folder's size I get a much smaller number. Folder and file types seem to have no impact on the issue. Notice that  the folder "Charlie***" shows 500 megs but when I open it and highlight the folders in it  it shows 57 gigs....Which is ALSO  wrong! There iare over 100 gigs in that folder

    LOL, Good luck :)

    Was this answer helpful?

    5 people found this answer helpful.
    0 comments No comments
  5. Anonymous
    2018-05-03T21:16:44+00:00

    Please file a bug report and send me the short link so I can send it to the engineers:

    Press Windows key + F

    This will open the Feedback hub

    Proceed to submit your report.

    Feedback:

    You can reach out to key folks on the Windows Engineering team through Twitter

    https://twitter.com/donasarkar

    https://twitter.com/brandonleblanc

    https://twitter.com/jenmsft

    https://twitter.com/northfacehiker

    Make sure you send short link to them. They are known to be very responsive and might be able to point it in the right direction.

    Remember to send me the short link.

    Was this answer helpful?

    5 people found this answer helpful.
    0 comments No comments