I've had a Buffalo LS420D 4TB NTFS network drive for years (no special setup - just whatever was the default as far as I can remember), but I just now noticed that no matter how small a file actually is, if I right-click on it and choose Properties, the "Size on disk" claims to be 128MB! I searched around and found a file whose real size was slightly bigger than that, and yup, the "Size on disk" for that one jumped to 256MB. (Command line dir reports the same as the "Size" line in Properties.) Curious how far the absurdity would go, I asked for the Properties on the folder I know has the most files - an old but massive clipart collection. I had to let it run overnight, but yup, it was pretty hilarious - 76TB! Below are screenshots of the craziness. I'm viewing it with Windows 10 64-bit, if that matters. What's going on?

Tiny test file

Directory of many small files

Additional info in response to multiple comments:

  • My NAS drive's firmware is already on the most current version (1.81). I apparently bought the drive more recently than I thought, because that version was released June 2015.
  • I don't know how to determine the NTFS cluster size, but this page seems to say that the default would be 4kB, and I'm pretty sure I didn't deviate from that (I don't even know how). But if you want me to check directly, please tell me how, because googling did not reveal such instruction. (chkdsk: "Windows cannot check a disk attached through a network." fsutil: "The FSUTIL utility requires a local NTFS volume.")
  • At Larssend's insistence I installed Wireshark and saved a brief capture during which I viewed Properties on my 3-byte text.txt and then opened the same file in Notepad. I have no idea how to interpret the log of interactions, so I have uploaded it as binary Wireshark file and exported plain text. is my PC and is the NAS drive ( is my printer, which was idle - I'm not sure why there was chatter with that).

I considered connecting via USB to see if it acted the same way, but I don't have the right cable - the drive's USB jack is Type-A (thin rectangle) instead of the expected Type-B (square with two angled corners), and I don't have a cable with Type-A on both ends.

  • 1
    It looks like your Art folder has...exploded Apr 24, 2017 at 1:18
  • 1
    Capture your network using Wireshark while accessing test.txt and analyze the capture data. Close other network/Internet programs before starting the capture to minimize noise.This will help you verify the source of the problem (either your NAS or Windows). I suspect your NAS is to blame for reporting the wrong allocation size.
    – Larssend
    Apr 24, 2017 at 1:52
  • 2
    Can you tell more about the specification / configuration of your "4TB NTFS network drive"?
    – Kenneth L
    Apr 24, 2017 at 1:57
  • 1
    Seems to be a known 'problem' community.netgear.com/t5/Using-your-ReadyNAS/…
    – eckes
    Apr 24, 2017 at 5:56
  • 1
    NAS means an appliance which makes storage available on the network (including your LAN). Your NAS has a firmware and according to the discussion I linked it might fix that problem in a later version.
    – eckes
    Apr 24, 2017 at 8:05

1 Answer 1


From your Wireshark capture file, in packet no. 17:

    Allocation Size: 134217728
    End Of File: 3
    Link Count: 1
    Delete Pending: Normal, no pending delete (0)
    Is Directory: This is NOT a directory (0)
    Unknown Data: 0000

Your NAS is reporting 134217728 bytes, which equals to 128MB assuming 1024 bytes in 1 KB, of allocated size (or 'size on disk') for test.txt. So the problem is on your NAS side. The obvious solution is to update the firmware and/or operating system on your NAS (assuming there is any such update available). If there is no update available, you will have to report the bug to the vendor (Buffalo).

  • The firmware is already current (version 1.81, released June 2015), and that model of drive appears to be out of production now, so I doubt that reporting it would cause them to make an update to firmware at this point. What sort of consequences could I run into by ignoring it? Apr 26, 2017 at 0:24
  • @OsakaWebbie: I wouldn't know. I can't simulate this kind of problem, so I can't do any kind of testing.
    – Larssend
    Apr 26, 2017 at 2:01
  • I don't think this has any consequences besides you have imprecise sizing statistics
    – eckes
    Apr 26, 2017 at 5:00
  • @Larssend: By the way, how in the world did you find that packet info? The text file is utterly useless (the number 134217728 does not appear at all), and in Wireshark I was only able to find what you posted by clicking on #17 and drilling down several layers in the lower pane (Frame 17... -> SMB -> Trans2 Response (0x32) -> QUERY_PATH_INFO Data). There were almost 900 packets in that log, and a lot of layers of data in each one - how did you know what to look for and where to look? Apr 26, 2017 at 7:00
  • @OsakaWebbie: in Wireshark, click packet no. 17, then in the middle pane, expand SMB (Server Message Block Protocol) > Trans2 Response > QUERY_PATH_INFO_DATA.
    – Larssend
    Apr 26, 2017 at 7:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .