Hopefully my screenshot is clear.

https://www.dropbox.com/scl/fi/jo4coaf49i7fkm2zjpzrb/MajorDiscrepancy.jpg?rlkey=qxl6lct3eah7qfpyay1r9ji4m&raw=1

All other tools and visual observation confirm that the parent folder
contains 196 folders and three files. Most folders \xyz have one file
named xyz.ino in case that's relevant. And the parent is C:\Users\terry\Dropbox\Electronics\Arduino\SKETCHES\My Sketches\FORUM.

I'm wondering if some issue at Dropbox is involved, and I'll pursue that
too. I've used Dropbox for many years and not come across this before.
But how could File Explorer get it so wrong?

Terry

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 6/28/2025 9:47 AM, Terry Pinnell wrote:

Hopefully my screenshot is clear.

https://www.dropbox.com/scl/fi/jo4coaf49i7fkm2zjpzrb/MajorDiscrepancy.jpg?rlkey=qxl6lct3eah7qfpyay1r9ji4m&raw=1

All other tools and visual observation confirm that the parent folder contains 196 folders and three files. Most folders \xyz have one file
named xyz.ino in case that's relevant. And the parent is C:\Users\terry\Dropbox\Electronics\Arduino\SKETCHES\My Sketches\FORUM.

I'm wondering if some issue at Dropbox is involved, and I'll pursue that
too. I've used Dropbox for many years and not come across this before.
But how could File Explorer get it so wrong?

Terry

File Explorer shows the visible item count, as a function of the
Folder Options setting. If you ask it to show hidden system files,
then a few extra files show up in C:\ for example, and the item
count should correspond to the rows in the display.

File Explorer supports library projections. The library is
both virtual and physical (a collection of folders mashed together).

If you list a directory that has a Library Projection in it,
that will give one line in File Explorer. Whereas if you go
to Command Prompt and do a "dir", the Library Projection is missing.

What "trick" would a Dropbox be using ?

Does the "trick" fool the dir command in a Command Prompt ?

There is no single utility that "does it all". You have to use
a collection of utilities, like Junction, to try to list the
contents of C: in an intelligible manner. If I was on-site,
it would take me a while, to rationalize the item count you see.

I started writing my own utility to list files, but it isn't
going well. Down near the end of the $MFT are some items
that make no sense. Like, a file without a file name. And the
NTFS version number, they claim it hasn't changed <snicker>.
Running a CHKDSK, leaves that section of the $MFT, unchanged.

At one time, the "icacls" utility that ships with Windows, had
a compact representation for permissions. Then, after the monkeys
got at it, now if you use "icacls", it is full of "plain english descriptors" which have no abbreviation, and they cover off the abominations
added to the security model. It looks like shit.

IDK. It's a job I guess. For somebody.

Paul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Terry Pinnell <me@somewhere.invalid> wrote:

Hopefully my screenshot is clear.

https://www.dropbox.com/scl/fi/jo4coaf49i7fkm2zjpzrb/MajorDiscrepancy.jpg?rlkey=qxl6lct3eah7qfpyay1r9ji4m&raw=1

All other tools and visual observation confirm that the parent folder >contains 196 folders and three files. Most folders \xyz have one file
named xyz.ino in case that's relevant. And the parent is >C:\Users\terry\Dropbox\Electronics\Arduino\SKETCHES\My Sketches\FORUM.

I'm wondering if some issue at Dropbox is involved, and I'll pursue that
too. I've used Dropbox for many years and not come across this before.
But how could File Explorer get it so wrong?

Terry

Thanks both.

Has anyone tried to reproduce? Takes less than a minute, and would at
least establish if it was just me.

I always have 'Show hidden files, folders and drives' enabled.

Terry

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 6/29/2025 7:43 AM, Terry Pinnell wrote:

Terry Pinnell <me@somewhere.invalid> wrote:

Hopefully my screenshot is clear.

https://www.dropbox.com/scl/fi/jo4coaf49i7fkm2zjpzrb/MajorDiscrepancy.jpg?rlkey=qxl6lct3eah7qfpyay1r9ji4m&raw=1

All other tools and visual observation confirm that the parent folder
contains 196 folders and three files. Most folders \xyz have one file
named xyz.ino in case that's relevant. And the parent is
C:\Users\terry\Dropbox\Electronics\Arduino\SKETCHES\My Sketches\FORUM.

I'm wondering if some issue at Dropbox is involved, and I'll pursue that
too. I've used Dropbox for many years and not come across this before.
But how could File Explorer get it so wrong?

Terry

Thanks both.

Has anyone tried to reproduce? Takes less than a minute, and would at
least establish if it was just me.

I always have 'Show hidden files, folders and drives' enabled.

Terry

And if the left-hand "113 items" refers to "113 rows",
while the right-hand properties refers to a recursive listing
of everything in those folders (folders within folders), what then ?
You may be interpreting what you see, too literally, when the machine
loves to use different perspectives in its interfaces.

I use nfi.exe when I want real details.

*******

This is an example of a Microsoft Mystery-Meat.

File 279124
(unknown/unnamed) <=== Um, please, spare me the puzzles
$FILE_NAME (resident)
$FILE_NAME (resident) <=== the file name should be inside things like this
$DATA (nonresident)
logical sectors 5415560-5415959 (0x52a288-0x52a417)
$EA_INFORMATION (resident)
$EA (resident)
Attribute Type 0x100 $DSC (resident) <=== has the name been overridden by an Extended Attribute ?
Attribute Type 0x100 $TXF_DATA (resident <=== If I used Windows 7 CHKDSK and these got removed, what then ?

*******

I can step along, and see all the files in a folder, whether they are Hidden, System, Archive
or whatever. Anything projected, won't be in here. But if I need a precise count, this is
how I do it. nfi.exe . This was written in 2003, and I am unaware of anyone making an
up-to-date version.

File 41 \Windows\ServiceProfiles\NetworkService\AppData\Local\Microsoft\Windows\DeliveryOptimization\State\migration.dat
File 72202 \Windows\ServiceProfiles\NetworkService\AppData\Local\Microsoft\Windows\DeliveryOptimization\State\migration.dat.LOG1
File 72203 \Windows\ServiceProfiles\NetworkService\AppData\Local\Microsoft\Windows\DeliveryOptimization\State\migration.dat.LOG2
File 96340 \Windows\ServiceProfiles\NetworkService\AppData\Local\Microsoft\Windows\DeliveryOptimization\State\dosvcState.dat
File 96341 \Windows\ServiceProfiles\NetworkService\AppData\Local\Microsoft\Windows\DeliveryOptimization\State\dosvcState.dat.LOG1
File 96342 \Windows\ServiceProfiles\NetworkService\AppData\Local\Microsoft\Windows\DeliveryOptimization\State\dosvcState.dat.LOG2
File 96343 \Windows\ServiceProfiles\NetworkService\AppData\Local\Microsoft\Windows\DeliveryOptimization\State\keyValueLKG.dat

The "everything.exe", it could not list the loose files in WSL1 folder. Everything.exe uses the $MFT, but the instant it tries to decorate the
display with accurate file sizes, then anything with "permission denied"
cannot be listed. That's how you lose some of the content with that one.

But rest assured, the two displays are not "working at the same level",
so no lie is happening. The "item" notion, is a count of the lines
in the display that you have just selected by some means. It isn't a count
of primitives held within the folders, which could be quite a lot more numerous.

Paul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Paul <nospam@needed.invalid> wrote:

You may be interpreting what you see, too literally, when the machine
loves to use different perspectives in its interfaces.

Indeed, thanks, my bad!

'Items' is not the total number of files as I'd assumed. It's simply the
number of 'independent' files plus the number of subfolders, both in the
'root of the parent. IOW, just the number of line entries.

Terry

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Terry Pinnell <me@somewhere.invalid> wrote:

Hopefully my screenshot is clear.

https://www.dropbox.com/scl/fi/jo4coaf49i7fkm2zjpzrb/MajorDiscrepancy.jpg?rlkey=qxl6lct3eah7qfpyay1r9ji4m&raw=1

All other tools and visual observation confirm that the parent folder contains 196 folders and three files. Most folders \xyz have one file
named xyz.ino in case that's relevant. And the parent is C:\Users\terry\Dropbox\Electronics\Arduino\SKETCHES\My Sketches\FORUM.

I'm wondering if some issue at Dropbox is involved, and I'll pursue that
too. I've used Dropbox for many years and not come across this before.
But how could File Explorer get it so wrong?

You already mentioned you have File Explorer show hidden and system
files. Usually when in that view, you often see desktop.ini files for
tracking customization of a folder.

Were you logged in at the time under a limited Windows account? Or when
logged in under an admin-level Windows account?

Some programs will attempt to hide files as a means of protection, like
a anti-ransom feature. My backup program has an option to use a driver
to limit access to its backup files to restrict write, rename, move, or
other file I/O actions. That used a stacked file I/O driver to restrict
any access to its backup files to just the backup program itself. I
remember trying something in the past that created snapshots of the
drive (might've been Comodo Time Machine, but it was far too flaky, and
caused file corruption for many users) to let you restore to a prior
state, and they hid their snapshot files, but that also caused problems
with file tools, and anything that resized a partition based of what was detected as unused space. Because the snapshot files were hidden,
non-aware tools could easily eliminate them. They also used a stacked
file I/O driver to hide the files from user processes. Have you
rebooted into Windows Safe Mode to recheck the folder and file count?

Maybe it's about time to run "chkdsk /r /f" to ensure you don't have
problems with linkages or definitions in the file system.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Paul <nospam@needed.invalid> wrote:

I started writing my own utility to list files, but it isn't
going well. Down near the end of the $MFT are some items
that make no sense. Like, a file without a file name.

Windows will store a "file" within the MFT record if the contents will
fit inside the MFT record (1024 bytes). No point in having an MFT
record point at a seperate sector offset to store a file when the "file"
could inside an MFT record. The MFT is a file itself within the file
system, and its records are fixed in size, so a small file goes inside
the record. Files stored inside MFT records are called resident files.

https://en.wikipedia.org/wiki/NTFS#Resident_vs._non-resident_attributes

If you use non-standard MFT allocation unit sizing, the max size for a
resident file changes.

There are two identical MFTs: main one is on the outer tracks of an HDD,
and second is halfway in the platter. The outer would have faster
access. The middle one is for redundancy, and for corruption recovery.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Terry Pinnell <me@somewhere.invalid> wrote:

Hopefully my screenshot is clear.

https://www.dropbox.com/scl/fi/jo4coaf49i7fkm2zjpzrb/MajorDiscrepancy.jpg?rlkey=qxl6lct3eah7qfpyay1r9ji4m&raw=1

All other tools and visual observation confirm that the parent folder contains 196 folders and three files. Most folders \xyz have one file
named xyz.ino in case that's relevant. And the parent is C:\Users\terry\Dropbox\Electronics\Arduino\SKETCHES\My Sketches\FORUM.

I'm wondering if some issue at Dropbox is involved, and I'll pursue that
too. I've used Dropbox for many years and not come across this before.
But how could File Explorer get it so wrong?

If I have a folder with contents like this

    +- SubFolder1
    |   +- File4
    +- SubFolder2
    |   +- File5
    +- File3


The bottom left corner of File Explorer will show 3 items because it
does not count the items inside subfolders.

The properties dialog will show 5 items (at least) because it does count
the items in subfolders.

No surprise that the two numbers are different.


Perry.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

"winston" <winstonmvp@gmail.com> wrote:

VanguardLH wrote:

You already mentioned you have File Explorer show hidden and system
files. Usually when in that view, you often see desktop.ini files for
tracking customization of a folder.

FYI...
TP said
"I always have 'Show hidden files, folders and drives' enabled."

For the above setting desktop.ini files are *not* shown

The setting that shows desktop.ini files is the other one(when unchecked)
'Hide protected operating system files'

One option is *only* for "hidden". The other option is for "system".
I did say "and", so enable both options.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

"P. Tyndale" <not@here.invalid> wrote:

Terry Pinnell <me@somewhere.invalid> wrote:

Hopefully my screenshot is clear.

https://www.dropbox.com/scl/fi/jo4coaf49i7fkm2zjpzrb/MajorDiscrepancy.jpg?rlkey=qxl6lct3eah7qfpyay1r9ji4m&raw=1

All other tools and visual observation confirm that the parent folder
contains 196 folders and three files. Most folders \xyz have one file
named xyz.ino in case that's relevant. And the parent is
C:\Users\terry\Dropbox\Electronics\Arduino\SKETCHES\My Sketches\FORUM.

I'm wondering if some issue at Dropbox is involved, and I'll pursue that
too. I've used Dropbox for many years and not come across this before.
But how could File Explorer get it so wrong?

If I have a folder with contents like this

    +- SubFolder1
    |   +- File4
    +- SubFolder2
    |   +- File5
    +- File3

The bottom left corner of File Explorer will show 3 items because it
does not count the items inside subfolders.

The properties dialog will show 5 items (at least) because it does count
the items in subfolders.

No surprise that the two numbers are different.

I use the free version of TreeSize to see the size of a folder as it
does recurse into subfolders. It is also accessible in the context menu
of File Explorer when you right-click on a folder. You might want to
run it under admin privileges to catch system files.

https://www.jam-software.com/treesize_free/comparison.shtml

There are alternatives, like WinDirStat (but I found its output clumsy,
and not as informative)

In a command shell, you can also run:

dir [<path>] /s

That can take a long time to generate pages of stdout. If you want the
details without having to scroll through the console window (which you
may need to enlarge its buffer to prevent truncation), pipe stdout to a
file, like:

dir [<path>]/s > %temp%\dirlist.txt && notepad %temp%\dirlist.txt

and wait until Notepad appears showing the list of [sub]folders and
files in each.

However, as mentioned, a stacked file I/O driver can still hide folders
and files from any user process, like the above.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-06-29 22:36, VanguardLH wrote:

Paul <nospam@needed.invalid> wrote:

I started writing my own utility to list files, but it isn't
going well. Down near the end of the $MFT are some items
that make no sense. Like, a file without a file name.

Windows will store a "file" within the MFT record if the contents will
fit inside the MFT record (1024 bytes).

Interesting. Reiserfs does the same trick on Linux.

No point in having an MFT
record point at a seperate sector offset to store a file when the "file" could inside an MFT record. The MFT is a file itself within the file
system, and its records are fixed in size, so a small file goes inside
the record. Files stored inside MFT records are called resident files.

https://en.wikipedia.org/wiki/NTFS#Resident_vs._non-resident_attributes

If you use non-standard MFT allocation unit sizing, the max size for a resident file changes.

There are two identical MFTs: main one is on the outer tracks of an HDD,
and second is halfway in the platter. The outer would have faster
access. The middle one is for redundancy, and for corruption recovery.

Are both written at the same time?

--
Cheers, Carlos.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-06-29 22:46, VanguardLH wrote:

Terry Pinnell <me@somewhere.invalid> wrote:

Hopefully my screenshot is clear.

https://www.dropbox.com/scl/fi/jo4coaf49i7fkm2zjpzrb/MajorDiscrepancy.jpg?rlkey=qxl6lct3eah7qfpyay1r9ji4m&raw=1

All other tools and visual observation confirm that the parent folder
contains 196 folders and three files. Most folders \xyz have one file
named xyz.ino in case that's relevant. And the parent is
C:\Users\terry\Dropbox\Electronics\Arduino\SKETCHES\My Sketches\FORUM.

I'm wondering if some issue at Dropbox is involved, and I'll pursue that
too. I've used Dropbox for many years and not come across this before.
But how could File Explorer get it so wrong?

You already mentioned you have File Explorer show hidden and system
files. Usually when in that view, you often see desktop.ini files for tracking customization of a folder.

Were you logged in at the time under a limited Windows account? Or when logged in under an admin-level Windows account?

Some programs will attempt to hide files as a means of protection, like
a anti-ransom feature. My backup program has an option to use a driver
to limit access to its backup files to restrict write, rename, move, or
other file I/O actions. That used a stacked file I/O driver to restrict
any access to its backup files to just the backup program itself. I
remember trying something in the past that created snapshots of the
drive (might've been Comodo Time Machine, but it was far too flaky, and caused file corruption for many users) to let you restore to a prior
state, and they hid their snapshot files, but that also caused problems
with file tools, and anything that resized a partition based of what was detected as unused space. Because the snapshot files were hidden,
non-aware tools could easily eliminate them. They also used a stacked
file I/O driver to hide the files from user processes. Have you
rebooted into Windows Safe Mode to recheck the folder and file count?

That's nasty. I always wondered if somebody did this.

Maybe it's about time to run "chkdsk /r /f" to ensure you don't have
problems with linkages or definitions in the file system.

--
Cheers, Carlos.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

"Carlos E.R." <robin_listas@es.invalid> wrote:

There are two identical MFTs: main one is on the outer tracks of an HDD,
and second is halfway in the platter. The outer would have faster
access. The middle one is for redundancy, and for corruption recovery.

Are both written at the same time?

I would assume so for both to be exactly the same. The duplicate is in
case one gets corrupted, like the sectors on the platter went bad. As
to how the OS does it, I don't know if the file I/O is duplicated and paralleled, or there is ensuing mirroring.

Filename for the MFT is $Mft, and for its mirror is $MftMirr.

The locations for the MFTs are recorded in the boot sector which is also duplicated at the middle of the drive.

https://www.file-recovery.com/recovery-NTFS-master-file-table-MFT.htm

However, the actual operation is never fully explained. Quite often I
see mention that $MftMirr mirrors, at least, the first 4 records of
$Mft, like "MFTMirr: A backup copy of the first 4 records of the MFT."
I'm not sure how just 4 file records are doable for file system
recovery. Perhaps $MftMirr is just for recovery of $Mft, like $Mft got deleted, so $MftMirr could be used to relocate its sectors, not for
recovery of files.

https://flatcap.github.io/linux-ntfs/ntfs/files/mftmirr.html https://bromiley.medium.com/ntfs-part-7-an-ntfs-story-caf42565855b

This is for NTFS. I doubt FAT (and bitwidth) has any file table
recovery scheme. While interesting, I've not much delved into NTFS
beyond what I had to know, or got curious about at the time.

So, my statement there are 2 identical MFTs appears incorrect. There is
$Mft for the file system table, and there's $MftMirr pointing to where
$Mft is stored.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-07-04 17:55, VanguardLH wrote:

"Carlos E.R." <robin_listas@es.invalid> wrote:

There are two identical MFTs: main one is on the outer tracks of an HDD, >>> and second is halfway in the platter. The outer would have faster
access. The middle one is for redundancy, and for corruption recovery.

Are both written at the same time?

I would assume so for both to be exactly the same. The duplicate is in
case one gets corrupted, like the sectors on the platter went bad. As
to how the OS does it, I don't know if the file I/O is duplicated and paralleled, or there is ensuing mirroring.

Filename for the MFT is $Mft, and for its mirror is $MftMirr.

The locations for the MFTs are recorded in the boot sector which is also duplicated at the middle of the drive.

https://www.file-recovery.com/recovery-NTFS-master-file-table-MFT.htm

However, the actual operation is never fully explained. Quite often I
see mention that $MftMirr mirrors, at least, the first 4 records of
$Mft, like "MFTMirr: A backup copy of the first 4 records of the MFT."
I'm not sure how just 4 file records are doable for file system
recovery. Perhaps $MftMirr is just for recovery of $Mft, like $Mft got deleted, so $MftMirr could be used to relocate its sectors, not for
recovery of files.

https://flatcap.github.io/linux-ntfs/ntfs/files/mftmirr.html https://bromiley.medium.com/ntfs-part-7-an-ntfs-story-caf42565855b

This is for NTFS. I doubt FAT (and bitwidth) has any file table
recovery scheme. While interesting, I've not much delved into NTFS
beyond what I had to know, or got curious about at the time.

FAT has a dual FAT system, both placed at the start of the disk, and
both were written in the same operation, or consecutive operations (the
head movement is minimal in floppies). And third party software could
make a copy of the FAT + directory structure somewhere else at some
point of the session, like when switching off the computer. I had a
power off BAT script that did that kind of stuff, and finally parked the
disk heads.

Third party software used that backup copy to try recover deleted on
error files.

So, my statement there are 2 identical MFTs appears incorrect. There is
$Mft for the file system table, and there's $MftMirr pointing to where
$Mft is stored.

--
Cheers, Carlos.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

VanguardLH <V@nguard.LH> wrote:

Terry Pinnell <me@somewhere.invalid> wrote:

Hopefully my screenshot is clear.

https://www.dropbox.com/scl/fi/jo4coaf49i7fkm2zjpzrb/MajorDiscrepancy.jpg?rlkey=qxl6lct3eah7qfpyay1r9ji4m&raw=1

All other tools and visual observation confirm that the parent folder
contains 196 folders and three files. Most folders \xyz have one file
named xyz.ino in case that's relevant. And the parent is
C:\Users\terry\Dropbox\Electronics\Arduino\SKETCHES\My Sketches\FORUM.

I'm wondering if some issue at Dropbox is involved, and I'll pursue that
too. I've used Dropbox for many years and not come across this before.
But how could File Explorer get it so wrong?

You already mentioned you have File Explorer show hidden and system
files. Usually when in that view, you often see desktop.ini files for >tracking customization of a folder.

Were you logged in at the time under a limited Windows account? Or when >logged in under an admin-level Windows account?

Some programs will attempt to hide files as a means of protection, like
a anti-ransom feature. My backup program has an option to use a driver
to limit access to its backup files to restrict write, rename, move, or
other file I/O actions. That used a stacked file I/O driver to restrict
any access to its backup files to just the backup program itself. I
remember trying something in the past that created snapshots of the
drive (might've been Comodo Time Machine, but it was far too flaky, and >caused file corruption for many users) to let you restore to a prior
state, and they hid their snapshot files, but that also caused problems
with file tools, and anything that resized a partition based of what was >detected as unused space. Because the snapshot files were hidden,
non-aware tools could easily eliminate them. They also used a stacked
file I/O driver to hide the files from user processes. Have you
rebooted into Windows Safe Mode to recheck the folder and file count?

Maybe it's about time to run "chkdsk /r /f" to ensure you don't have
problems with linkages or definitions in the file system.

Thanks, but turned out to be down to my incorrect interpretation of
"Items". As I said in my reply to Paul.

Terry

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

P. Tyndale <not@here.invalid> wrote:

No surprise that the two numbers are different.

Indeed. See my reply to Paul 12 days ago:
29/6/25, 15:36
Terry

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)