Fully updated Windows11. Once in a while I find some 'Fond nn' zero length
files in a directory. No problems from deleting them. Any idea where they
are coming from and/or why?

MajorLanGod <lonelydad58@gmail.com> wrote:

> Fully updated Windows11. Once in a while I find some 'Fond nn' zero length
> files in a directory. No problems from deleting them. Any idea where they
> are coming from and/or why?

Chkdsk. Whether you run it manually, or ran using Task Scheduler (*),
or it runs when a problem is found in the file system, it can create
those files from orphaned clusters in the file system.

(*) Even if you don't add your own events in Task Scheduler to
periodically run chkdsk on your drives, Microsoft already added a
scheduled event. In Task Manager, go to Task Scheduler library ->
Microsoft -> Windows under which you'll find a node for Chkdsk. For
the ProactiveScan event, look when it was last ran.

On 3/4/24 15:56, VanguardLH wrote:
> MajorLanGod <lonelydad58@gmail.com> wrote:
>
>> Fully updated Windows11. Once in a while I find some 'Fond nn' zero length
>> files in a directory. No problems from deleting them. Any idea where they
>> are coming from and/or why?
>
> Chkdsk. Whether you run it manually, or ran using Task Scheduler (*),
> or it runs when a problem is found in the file system, it can create
> those files from orphaned clusters in the file system.
>
> (*) Even if you don't add your own events in Task Scheduler to
> periodically run chkdsk on your drives, Microsoft already added a
> scheduled event. In Task Manager, go to Task Scheduler library ->
> Microsoft -> Windows under which you'll find a node for Chkdsk. For
> the ProactiveScan event, look when it was last ran.

And if you constantly get a lot of those found xx files,
you may have a disk that is degrading.

gsmartcontrol is a good way to check:
http://gsmartcontrol.sourceforge.net/home/index.php/Downloads

If it is degrading and yo have anything on your disk
that is of value to you, replace it.

T <T@invalid.invalid> wrote:

> On 3/4/24 15:56, VanguardLH wrote:
>> MajorLanGod <lonelydad58@gmail.com> wrote:
>>
>>> Fully updated Windows11. Once in a while I find some 'Fond nn' zero length
>>> files in a directory. No problems from deleting them. Any idea where they
>>> are coming from and/or why?
>>
>> Chkdsk. Whether you run it manually, or ran using Task Scheduler (*),
>> or it runs when a problem is found in the file system, it can create
>> those files from orphaned clusters in the file system.
>>
>> (*) Even if you don't add your own events in Task Scheduler to
>> periodically run chkdsk on your drives, Microsoft already added a
>> scheduled event. In Task Manager, go to Task Scheduler library ->
>> Microsoft -> Windows under which you'll find a node for Chkdsk. For
>> the ProactiveScan event, look when it was last ran.
>
> And if you constantly get a lot of those found xx files,
> you may have a disk that is degrading.
>
> gsmartcontrol is a good way to check:
> http://gsmartcontrol.sourceforge.net/home/index.php/Downloads
>
> If it is degrading and yo have anything on your disk
> that is of value to you, replace it.

The disk will have a fixed number of reserved sectors for remapping bad
sectors to reserved (good) sectors. Once that reserved is used up, no
more mapping of bad sectors. You end up with bad sectors that cannot be
copied and remapped to reserve sectors. Also, the more mapping the
slower the access to the data: access the original sector, remap to
reserved sector, and then read/write. Remapping takes times. Nothing
you might notice, but a lot of it aggregates to a lot of remap
operations on the disk.

One way to tell is to use any utility that shows you the S.M.A.R.T.
statistics on the disk. Look at the Current Pending Sector Count value
(SMART index 197). Only shown for HDDs, not SSDs (the OP didn't specify
what type of disk is reporting the "Found" files). It may be non-zero,
but should be zero after a reboot. The count may go up, because there
are bad sectors pending a remap, but the count should also go down. If
the pending count goes up and never resets to zero, all reserved sectors
have been consumed.

Alas, I've yet to find any drive maker that exposes just how many
reserved sectors they allocate on their products. I've seen monitor
tools that flag a drive as bad because there was a big jump in mapped
sectors, but they can't tell you how much of the reserved space got
consumed. You might see a jump of 200 bad sectors get mapped, but is
that a huge percentage of the reserved space? Yeah, if the reserved
space is only 1000 sectors, but no if reserved space is 10,000 sectors.
There can be a quick jump in reserved space consumption, and then it
levels out thereafter with no more bad sectors detected. So, you get a
momentary spike, the monitoring tool says your disk went bad, but the
disk is still very usable thereafter. What you need is a monitoring
tool that shows you a graph of the pending remap count. Without a
ceiling (the drive maker disclosing the total reserve space size), the
graph is only usable for telling you how often there are spikes, and
their magnitudes. You don't know how close you are getting to the
ceiling for reserved space.

There are health monitoring tools to watch for problems on disks. I use
HD Sentinel (https://www.hdsentinel.com/), but there are others (e.g.,
HD Tune, CrystalDiskInfo, smartmon, HDD Regenerator). You want
something that reports the SMART stats, and handy is to also show graphs
to see trends. The example I mentioned of a spike in remaps having the
tool warn the disk is failing was by HD Sentinel, but likely any other
monitoring tool noticing the spike in remaps might issue the same
warning. I changed the threshold, and the HDD lasted for many years
after. I did, however, look at the logs and graphs at monthly intervals
for about a year to see if it was a momentary spike, or remaps were
continuing to happen. Got 1 spike, ran "chkdsk /r", never saw another
spike. That's when I found out HD Sentinel nor any other utility could
tell you the ceiling for reserved space. If the drive makers published
that info, the tools would know better just how close you got to
consuming all of reserved space. The could alert on spikes, like over
200 remaps in a day, but also indicate how close you were to not having
any more reserve space, like their graph showing you are approaching the
ceiling.

Does gsmartcontrol actually monitor disk health, or is it a tool you run
to get current stats, and have to keep rerunning at intervals to do the
monitoring? From https://gsmartcontrol.shaduri.dev/screenshots, looks
like it is a one-shot or momentary check of SMART data, and not a
monitoring tool to show stats over time, or even alert you to a problem
until you next run it again.

MajorLanGod wrote on 3/4/24 4:12 PM:
> Fully updated Windows11. Once in a while I find some 'Fond nn' zero length
> files in a directory. No problems from deleting them. Any idea where they
> are coming from and/or why?
>
You'll get a few thoughts on the 'found nn' files.
The question you need to answer before any beneficial advice becomes worthy:

The location on your disk that those files are seen/found.

--
....w¡ñ§±¤ñ

On 3/5/24 07:40, VanguardLH wrote:
> Does gsmartcontrol actually monitor disk health, or is it a tool you run
> to get current stats, and have to keep rerunning at intervals to do the
> monitoring? Fromhttps://gsmartcontrol.shaduri.dev/screenshots, looks
> like it is a one-shot or momentary check of SMART data, and not a
> monitoring tool to show stats over time, or even alert you to a problem
> until you next run it again.

It is one shot. When I suspect or I am just checking a
customer's drive, it works out well. And yes, it does
check SMART. And it has a fast and a long error
test too. I will typically run the fast test.
They have a version for Linux too, which I will run
from my bootable Fedora flash drive, to rescue
machines with.

For folks that want to check on their own, I give them
Crystal Disk Info:
https://sourceforge.net/projects/crystaldiskinfo/files/
I stick it on their task bar and tell them to check it once
a week. Has a nice big "Good" box that I tell them
to look for.

I will have to try out your recommendation of
Hard Disk Sentinel. Usually, if any of the self correction
stuff starts to fail, I don't trust the drive anymore.
And the sooner I can get it replaced the better as cloning
can be difficult getting past bad spots. And when bad spots start
to show, I am suspicious that the disk has run out of "reserved
sectors". And when that starts to happen, the disk is in
really bad shape.

Supposedly Samsung can do it with their Magician utility
and I know Clonezilla can, which has saved my customer's
asses more than once when they let the errors go on too long.
Magician required to clone to one of their drives, which
is not an issue as I typically only sell Samsung drives.

On my system, which is currently on Fedora 39, I wrote
a start up pop up that tells me the SMART "media_errors".
And I can always run the full SMART when I want:

/dev/nvme0n1 S.M.A.R.T. Status

Smart Log for NVME device:nvme0n1 namespace-id:ffffffff
critical_warning : 0
temperature : 32 °C (305 K)
available_spare : 100%
available_spare_threshold : 10%
percentage_used : 2%
endurance group critical warning summary: 0
Data Units Read : 1194860774 (611.77 TB)
Data Units Written : 63566924 (32.55 TB)
host_read_commands : 3750470283
host_write_commands : 1277603232
controller_busy_time : 9962
power_cycles : 2591
power_on_hours : 5790
unsafe_shutdowns : 90
media_errors : 0
num_err_log_entries : 7005
Warning Temperature Time : 0
Critical Composite Temperature Time : 0
Temperature Sensor 1 : 32 °C (305 K)
Temperature Sensor 2 : 38 °C (311 K)
Thermal Management T1 Trans Count : 0
Thermal Management T2 Trans Count : 0
Thermal Management T1 Total Time : 0
Thermal Management T2 Total Time : 0

Linux has all the cool tools.

And for those that let things go to absolute hell because
consultants are such a big rip off, for ~1000 to 2000 U$D,
there is always

DriveSavers Data Recovery
415.382-8000
800.440.1904
www.drivesaversdatarecovery.com

I have an account with them.

-T

On 3/5/24 09:35, ...w¡ñ§±¤ñ wrote:
> MajorLanGod wrote on 3/4/24 4:12 PM:
>> Fully updated Windows11. Once in a while I find some 'Fond nn' zero
>> length
>> files in a directory. No problems from deleting them. Any idea where they
>> are coming from and/or why?
>>
> You'll get a few thoughts on the 'found nn' files.
> The question you need to answer before any beneficial advice becomes
> worthy:
>
> The location on your disk that those files are seen/found.
>
>

As shown in Windows Explorer or physically on the drive?

On 3/5/24 07:40, VanguardLH wrote:
> I use
> HD Sentinel (https://www.hdsentinel.com/)

I looked at it. I am reluctant to use anything
that might interfere with the built in journaling.
On Linux systems, the journaling is marvelous.
You never know you have any bad spots. (I had one
Linux server journal down to about 15% capacity
without issue. Never knew anything was wrong.)
NTFS in Widows has some kind of journaling, but I
do not know how it operates or how effective it
is. And Windows being the kluge it is, I am
not real trusting of it.

On 05/03/2024 06:51, T wrote:
> snip <
>
> And if you constantly get a lot of those found xx files,
> you may have a disk that is degrading.
>
> gsmartcontrol is a good way to check:
> http://gsmartcontrol.sourceforge.net/home/index.php/Downloads
>

Thanks. Forgot I had this.
Doesn't find my Windows NVMe drive (Samsung 960 EVO) but does find a
second NVMe drive.
When updating the Installer asks to remove old version before installing
the new.

--
Regards
wasbit

On 3/5/2024 12:35 PM, ...w¡ñ§±¤ñ wrote:
> MajorLanGod wrote on 3/4/24 4:12 PM:
>> Fully updated Windows11. Once in a while I find some 'Fond nn' zero length
>> files in a directory. No problems from deleting them. Any idea where they
>> are coming from and/or why?
>>
> You'll get a few thoughts on the 'found nn' files.
> The question you need to answer before any beneficial advice becomes worthy:
>
> The location on your disk that those files are seen/found.
>
>

Sample of the contents of a Found entry.

When CHKDSK finds these, it appears to be using the
"first available filenum slot" to create the linkage
so that the clusters won't be lost. For the resident
ones, it presumably copies the $MFT slot to this new
location. Typically, the ones below might use one cluster
(8 sectors, 4096 bytes per cluster standard). "Resident"
means the ~700 byte storage area of an MFT 1KB slot.

Using the logical sector number, and your hex editor,
you could visit the cluster in question, and see
what is in there. I dumped a bit of a dir entry and
one "cluster" entry found.

File 19
\found.000
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$INDEX_ROOT $I30 (resident)

File 21
\found.000\dir0000.chk
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$INDEX_ROOT $I30 (resident)
$INDEX_ALLOCATION $I30 (nonresident)
logical sectors 10308448-10308463 (0x9d4b60-0x9d4b6f) 10308448*512=5277925376 Offset in H: (bytes)
$BITMAP $I30 (resident)

INDX(
0025.xml <=== directory does refer to them as XML files
0026.xml

File 247080
\found.000\dir0000.chk\0005.xml
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$DATA (nonresident)
logical sectors 32777816-32777823 (0x1f42658-0x1f4265f) 32777816*512=16782241792 Offset in H: (bytes)

MICROS~1.TMP
a few hundred zeroes... This is NOT an XML file of course.
CoreIdleState::
clientStructs.cpp
SyncTelemetry
VolumeChangeNotification
MainThrhead Not a typo.

File 247081
\found.000\dir0000.chk\0006.xml
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$DATA (nonresident)
logical sectors 32777848-32777855 (0x1f42678-0x1f4267f)

File 247082
\found.000\dir0000.chk\0007.xml
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$DATA (nonresident)
logical sectors 32778536-32778543 (0x1f42928-0x1f4292f)

File 247083
\found.000\dir0000.chk\0008.xml
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$DATA (nonresident)
logical sectors 32778544-32778551 (0x1f42930-0x1f42937)

File 247088
\found.000\dir0000.chk\0009.xml
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$DATA (nonresident)
logical sectors 32778592-32778599 (0x1f42960-0x1f42967)

File 247089
\found.000\dir0000.chk\0010.xml
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$DATA (nonresident)
logical sectors 32778600-32778607 (0x1f42968-0x1f4296f)

File 247090
\found.000\dir0000.chk\0011.xml
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$DATA (nonresident)
logical sectors 32778608-32778615 (0x1f42970-0x1f42977)

File 247091
\found.000\dir0000.chk\0012.xml
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$DATA (resident)

File 247092
\found.000\dir0000.chk\0013.xml
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$DATA (nonresident)
logical sectors 32778616-32778623 (0x1f42978-0x1f4297f)

File 247093
\found.000\dir0000.chk\0014.xml
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$DATA (nonresident)
logical sectors 32778624-32778631 (0x1f42980-0x1f42987)

File 247094
\found.000\dir0000.chk\0015.xml
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$DATA (nonresident)
logical sectors 32778632-32778639 (0x1f42988-0x1f4298f)

File 247095
\found.000\dir0000.chk\0016.xml
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$DATA (nonresident)
logical sectors 32778640-32778647 (0x1f42990-0x1f42997)

File 247096
\found.000\dir0000.chk\0017.xml
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$DATA (resident)

File 247097
\found.000\dir0000.chk\0018.xml
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$DATA (resident)

File 247098
\found.000\dir0000.chk\0019.xml
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$DATA (resident)

File 247099
\found.000\dir0000.chk\0020.xml
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$DATA (resident)

File 247100
\found.000\dir0000.chk\0021.xml
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$DATA (resident)

File 247101
\found.000\dir0000.chk\0022.xml
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$DATA (resident)

File 247122
\found.000\dir0000.chk\0023.xml
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$DATA (resident)

File 247123
\found.000\dir0000.chk\0024.xml
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$DATA (resident)

File 247124
\found.000\dir0000.chk\0025.xml
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$DATA (resident)

File 247125
\found.000\dir0000.chk\0026.xml
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$DATA (resident)

File 247126
\found.000\dir0000.chk\0027.xml
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$DATA (resident)

File 247127
\found.000\dir0000.chk\0028.xml
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$DATA (resident)

File 247128
\found.000\dir0000.chk\0029.xml
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$DATA (resident)

File 247129
\found.000\dir0000.chk\0030.xml
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$DATA (resident)

File 247130
\found.000\dir0000.chk\0031.xml
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$DATA (resident)

File 247131
\found.000\dir0000.chk\0032.xml
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$DATA (resident)

File 247132
\found.000\dir0000.chk\0033.xml
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$DATA (nonresident)
logical sectors 32778648-32778655 (0x1f42998-0x1f4299f)

File 247133
\found.000\dir0000.chk\0034.xml
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$DATA (nonresident)
logical sectors 32778656-32778663 (0x1f429a0-0x1f429a7)

File 247134
\found.000\dir0000.chk\0035.xml
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$DATA (resident)

File 247135
\found.000\dir0000.chk\0036.xml
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$DATA (resident)

File 247136
\found.000\dir0000.chk\0037.xml
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$DATA (resident)

File 247137
\found.000\dir0000.chk\0038.xml
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$DATA (resident)

File 247138
\found.000\dir0000.chk\0039.xml
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$DATA (resident)

File 247139
\found.000\dir0000.chk\0040.xml
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$DATA (nonresident)
logical sectors 32778664-32778671 (0x1f429a8-0x1f429af)

File 247140
\found.000\dir0000.chk\0041.xml
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$DATA (nonresident)
logical sectors 32778672-32778679 (0x1f429b0-0x1f429b7)

File 247141
\found.000\dir0000.chk\0042.xml
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$DATA (nonresident)
logical sectors 32778680-32778687 (0x1f429b8-0x1f429bf)

File 247142
\found.000\dir0000.chk\0043.xml
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$DATA (resident)

File 247143
\found.000\dir0000.chk\0044.xml
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$DATA (resident)

File 247144
\found.000\dir0000.chk\0045.xml
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$DATA (nonresident)
logical sectors 32778688-32778695 (0x1f429c0-0x1f429c7)

File 247145
\found.000\dir0000.chk\0046.xml
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$DATA (nonresident)
logical sectors 32778696-32778703 (0x1f429c8-0x1f429cf)

Paul <nospam@needed.invalid> wrote in news:us9evu$ao3f$1@dont-email.me:

> On 3/5/2024 12:35 PM, ...w¡ñ§±¤ñ wrote:
>> MajorLanGod wrote on 3/4/24 4:12 PM:
>>> Fully updated Windows11. Once in a while I find some 'Fond nn' zero
>>> length files in a directory. No problems from deleting them. Any
>>> idea where they are coming from and/or why?
>>>
>> You'll get a few thoughts on the 'found nn' files.
>> The question you need to answer before any beneficial advice becomes
>> worthy:
>>
>> The location on your disk that those files are seen/found.
>>
>>
>
> Sample of the contents of a Found entry.
>
> When CHKDSK finds these, it appears to be using the
> "first available filenum slot" to create the linkage
> so that the clusters won't be lost. For the resident
> ones, it presumably copies the $MFT slot to this new
> location. Typically, the ones below might use one cluster
> (8 sectors, 4096 bytes per cluster standard). "Resident"
> means the ~700 byte storage area of an MFT 1KB slot.
>
> Using the logical sector number, and your hex editor,
> you could visit the cluster in question, and see
> what is in there. I dumped a bit of a dir entry and
> one "cluster" entry found.
>
> File 19
> \found.000
> $STANDARD_INFORMATION (resident)
> $FILE_NAME (resident)
> $INDEX_ROOT $I30 (resident)
>
> File 21
> \found.000\dir0000.chk
> $STANDARD_INFORMATION (resident)
> $FILE_NAME (resident)
> $INDEX_ROOT $I30 (resident)
> $INDEX_ALLOCATION $I30 (nonresident)
> logical sectors 10308448-10308463 (0x9d4b60-0x9d4b6f)
> 10308448*512=5277925376 Offset in H: (bytes)
> $BITMAP $I30 (resident)
>
> INDX(
> 0025.xml <=== directory does refer to them as XML files
> 0026.xml
>
> File 247080
> \found.000\dir0000.chk\0005.xml
> $STANDARD_INFORMATION (resident)
> $FILE_NAME (resident)
> $DATA (nonresident)
> logical sectors 32777816-32777823 (0x1f42658-0x1f4265f)
> 32777816*512=16782241792 Offset in H: (bytes)
>
> MICROS~1.TMP
> a few hundred zeroes... This is NOT an XML file of
> course. CoreIdleState::
> clientStructs.cpp
> SyncTelemetry
> VolumeChangeNotification
> MainThrhead Not a typo.
>
> File 247081
> \found.000\dir0000.chk\0006.xml
> $STANDARD_INFORMATION (resident)
> $FILE_NAME (resident)
> $DATA (nonresident)
> logical sectors 32777848-32777855 (0x1f42678-0x1f4267f)
>
> File 247082
> \found.000\dir0000.chk\0007.xml
> $STANDARD_INFORMATION (resident)
> $FILE_NAME (resident)
> $DATA (nonresident)
> logical sectors 32778536-32778543 (0x1f42928-0x1f4292f)
>
> File 247083
> \found.000\dir0000.chk\0008.xml
> $STANDARD_INFORMATION (resident)
> $FILE_NAME (resident)
> $DATA (nonresident)
> logical sectors 32778544-32778551 (0x1f42930-0x1f42937)
>
> File 247088
> \found.000\dir0000.chk\0009.xml
> $STANDARD_INFORMATION (resident)
> $FILE_NAME (resident)
> $DATA (nonresident)
> logical sectors 32778592-32778599 (0x1f42960-0x1f42967)
>
> File 247089
> \found.000\dir0000.chk\0010.xml
> $STANDARD_INFORMATION (resident)
> $FILE_NAME (resident)
> $DATA (nonresident)
> logical sectors 32778600-32778607 (0x1f42968-0x1f4296f)
>
> File 247090
> \found.000\dir0000.chk\0011.xml
> $STANDARD_INFORMATION (resident)
> $FILE_NAME (resident)
> $DATA (nonresident)
> logical sectors 32778608-32778615 (0x1f42970-0x1f42977)
>
> File 247091
> \found.000\dir0000.chk\0012.xml
> $STANDARD_INFORMATION (resident)
> $FILE_NAME (resident)
> $DATA (resident)
>
> File 247092
> \found.000\dir0000.chk\0013.xml
> $STANDARD_INFORMATION (resident)
> $FILE_NAME (resident)
> $DATA (nonresident)
> logical sectors 32778616-32778623 (0x1f42978-0x1f4297f)
>
> File 247093
> \found.000\dir0000.chk\0014.xml
> $STANDARD_INFORMATION (resident)
> $FILE_NAME (resident)
> $DATA (nonresident)
> logical sectors 32778624-32778631 (0x1f42980-0x1f42987)
>
> File 247094
> \found.000\dir0000.chk\0015.xml
> $STANDARD_INFORMATION (resident)
> $FILE_NAME (resident)
> $DATA (nonresident)
> logical sectors 32778632-32778639 (0x1f42988-0x1f4298f)
>
> File 247095
> \found.000\dir0000.chk\0016.xml
> $STANDARD_INFORMATION (resident)
> $FILE_NAME (resident)
> $DATA (nonresident)
> logical sectors 32778640-32778647 (0x1f42990-0x1f42997)
>
> File 247096
> \found.000\dir0000.chk\0017.xml
> $STANDARD_INFORMATION (resident)
> $FILE_NAME (resident)
> $DATA (resident)
>
> File 247097
> \found.000\dir0000.chk\0018.xml
> $STANDARD_INFORMATION (resident)
> $FILE_NAME (resident)
> $DATA (resident)
>
> File 247098
> \found.000\dir0000.chk\0019.xml
> $STANDARD_INFORMATION (resident)
> $FILE_NAME (resident)
> $DATA (resident)
>
> File 247099
> \found.000\dir0000.chk\0020.xml
> $STANDARD_INFORMATION (resident)
> $FILE_NAME (resident)
> $DATA (resident)
>
> File 247100
> \found.000\dir0000.chk\0021.xml
> $STANDARD_INFORMATION (resident)
> $FILE_NAME (resident)
> $DATA (resident)
>
> File 247101
> \found.000\dir0000.chk\0022.xml
> $STANDARD_INFORMATION (resident)
> $FILE_NAME (resident)
> $DATA (resident)
>
> File 247122
> \found.000\dir0000.chk\0023.xml
> $STANDARD_INFORMATION (resident)
> $FILE_NAME (resident)
> $DATA (resident)
>
> File 247123
> \found.000\dir0000.chk\0024.xml
> $STANDARD_INFORMATION (resident)
> $FILE_NAME (resident)
> $DATA (resident)
>
> File 247124
> \found.000\dir0000.chk\0025.xml
> $STANDARD_INFORMATION (resident)
> $FILE_NAME (resident)
> $DATA (resident)
>
> File 247125
> \found.000\dir0000.chk\0026.xml
> $STANDARD_INFORMATION (resident)
> $FILE_NAME (resident)
> $DATA (resident)
>
> File 247126
> \found.000\dir0000.chk\0027.xml
> $STANDARD_INFORMATION (resident)
> $FILE_NAME (resident)
> $DATA (resident)
>
> File 247127
> \found.000\dir0000.chk\0028.xml
> $STANDARD_INFORMATION (resident)
> $FILE_NAME (resident)
> $DATA (resident)
>
> File 247128
> \found.000\dir0000.chk\0029.xml
> $STANDARD_INFORMATION (resident)
> $FILE_NAME (resident)
> $DATA (resident)
>
> File 247129
> \found.000\dir0000.chk\0030.xml
> $STANDARD_INFORMATION (resident)
> $FILE_NAME (resident)
> $DATA (resident)
>
> File 247130
> \found.000\dir0000.chk\0031.xml
> $STANDARD_INFORMATION (resident)
> $FILE_NAME (resident)
> $DATA (resident)
>
> File 247131
> \found.000\dir0000.chk\0032.xml
> $STANDARD_INFORMATION (resident)
> $FILE_NAME (resident)
> $DATA (resident)
>
> File 247132
> \found.000\dir0000.chk\0033.xml
> $STANDARD_INFORMATION (resident)
> $FILE_NAME (resident)
> $DATA (nonresident)
> logical sectors 32778648-32778655 (0x1f42998-0x1f4299f)
>
> File 247133
> \found.000\dir0000.chk\0034.xml
> $STANDARD_INFORMATION (resident)
> $FILE_NAME (resident)
> $DATA (nonresident)
> logical sectors 32778656-32778663 (0x1f429a0-0x1f429a7)
>
> File 247134
> \found.000\dir0000.chk\0035.xml
> $STANDARD_INFORMATION (resident)
> $FILE_NAME (resident)
> $DATA (resident)
>
> File 247135
> \found.000\dir0000.chk\0036.xml
> $STANDARD_INFORMATION (resident)
> $FILE_NAME (resident)
> $DATA (resident)
>
> File 247136
> \found.000\dir0000.chk\0037.xml
> $STANDARD_INFORMATION (resident)
> $FILE_NAME (resident)
> $DATA (resident)
>
> File 247137
> \found.000\dir0000.chk\0038.xml
> $STANDARD_INFORMATION (resident)
> $FILE_NAME (resident)
> $DATA (resident)
>
> File 247138
> \found.000\dir0000.chk\0039.xml
> $STANDARD_INFORMATION (resident)
> $FILE_NAME (resident)
> $DATA (resident)
>
> File 247139
> \found.000\dir0000.chk\0040.xml
> $STANDARD_INFORMATION (resident)
> $FILE_NAME (resident)
> $DATA (nonresident)
> logical sectors 32778664-32778671 (0x1f429a8-0x1f429af)
>
> File 247140
> \found.000\dir0000.chk\0041.xml
> $STANDARD_INFORMATION (resident)
> $FILE_NAME (resident)
> $DATA (nonresident)
> logical sectors 32778672-32778679 (0x1f429b0-0x1f429b7)
>
> File 247141
> \found.000\dir0000.chk\0042.xml
> $STANDARD_INFORMATION (resident)
> $FILE_NAME (resident)
> $DATA (nonresident)
> logical sectors 32778680-32778687 (0x1f429b8-0x1f429bf)
>
> File 247142
> \found.000\dir0000.chk\0043.xml
> $STANDARD_INFORMATION (resident)
> $FILE_NAME (resident)
> $DATA (resident)
>
> File 247143
> \found.000\dir0000.chk\0044.xml
> $STANDARD_INFORMATION (resident)
> $FILE_NAME (resident)
> $DATA (resident)
>
> File 247144
> \found.000\dir0000.chk\0045.xml
> $STANDARD_INFORMATION (resident)
> $FILE_NAME (resident)
> $DATA (nonresident)
> logical sectors 32778688-32778695 (0x1f429c0-0x1f429c7)
>
> File 247145
> \found.000\dir0000.chk\0046.xml
> $STANDARD_INFORMATION (resident)
> $FILE_NAME (resident)
> $DATA (nonresident)
> logical sectors 32778696-32778703 (0x1f429c8-0x1f429cf)
>
> File 247146
> \found.000\dir0000.chk\0047.xml
> $STANDARD_INFORMATION (resident)
> $FILE_NAME (resident)
> $DATA (nonresident)
> logical sectors 32778704-32778711 (0x1f429d0-0x1f429d7)
>
> File 247147
> \found.000\dir0000.chk\0048.xml
> $STANDARD_INFORMATION (resident)
> $FILE_NAME (resident)
> $DATA (nonresident)
> logical sectors 32778712-32778719 (0x1f429d8-0x1f429df)
>
> File 247148
> \found.000\dir0000.chk\0049.xml
> $STANDARD_INFORMATION (resident)
> $FILE_NAME (resident)
> $DATA (nonresident)
> logical sectors 32778784-32778791 (0x1f42a20-0x1f42a27)
>
> File 247149
> \found.000\dir0000.chk\0050.xml
> $STANDARD_INFORMATION (resident)
> $FILE_NAME (resident)
> $DATA (nonresident)
> logical sectors 32778792-32778799 (0x1f42a28-0x1f42a2f)
>
> File 247150
> \found.000\dir0000.chk\0051.xml
> $STANDARD_INFORMATION (resident)
> $FILE_NAME (resident)
> $DATA (nonresident)
> logical sectors 32778800-32778807 (0x1f42a30-0x1f42a37)
>
> File 247151
> \found.000\dir0000.chk\0052.xml
> $STANDARD_INFORMATION (resident)
> $FILE_NAME (resident)
> $DATA (nonresident)
> logical sectors 32778808-32778815 (0x1f42a38-0x1f42a3f)
>
> File 247156
> \found.000\dir0000.chk\0054.xml
> $STANDARD_INFORMATION (resident)
> $FILE_NAME (resident)
> $DATA (nonresident)
> logical sectors 32779680-32779687 (0x1f42da0-0x1f42da7)
>
> Paul
>
>

On 3/6/2024 1:03 PM, MajorLanGod wrote:
> Paul <nospam@needed.invalid> wrote in news:us9evu$ao3f$1@dont-email.me:
>
>> On 3/5/2024 12:35 PM, ...w¡ñ§±¤ñ wrote:
>>> MajorLanGod wrote on 3/4/24 4:12 PM:
>>>> Fully updated Windows11. Once in a while I find some 'Fond nn' zero
>>>> length files in a directory. No problems from deleting them. Any
>>>> idea where they are coming from and/or why?
>>>>
>>> You'll get a few thoughts on the 'found nn' files.
>>> The question you need to answer before any beneficial advice becomes
>>> worthy:
>>>
>>> The location on your disk that those files are seen/found.
>>>
>>>
>>
>> Sample of the contents of a Found entry.
>>
>> When CHKDSK finds these, it appears to be using the
>> "first available filenum slot" to create the linkage
>> so that the clusters won't be lost. For the resident
>> ones, it presumably copies the $MFT slot to this new
>> location. Typically, the ones below might use one cluster
>> (8 sectors, 4096 bytes per cluster standard). "Resident"
>> means the ~700 byte storage area of an MFT 1KB slot.
>>
>> Using the logical sector number, and your hex editor,
>> you could visit the cluster in question, and see
>> what is in there. I dumped a bit of a dir entry and
>> one "cluster" entry found.
>>
>> File 19
>> \found.000
>> $STANDARD_INFORMATION (resident)
>> $FILE_NAME (resident)
>> $INDEX_ROOT $I30 (resident)
>>
>> File 21
>> \found.000\dir0000.chk
>> $STANDARD_INFORMATION (resident)
>> $FILE_NAME (resident)
>> $INDEX_ROOT $I30 (resident)
>> $INDEX_ALLOCATION $I30 (nonresident)
>> logical sectors 10308448-10308463 (0x9d4b60-0x9d4b6f)
>> 10308448*512=5277925376 Offset in H: (bytes)
>> $BITMAP $I30 (resident)
>>
>> INDX(
>> 0025.xml <=== directory does refer to them as XML files
>> 0026.xml
>>
>> File 247080
>> \found.000\dir0000.chk\0005.xml
>> $STANDARD_INFORMATION (resident)
>> $FILE_NAME (resident)
>> $DATA (nonresident)
>> logical sectors 32777816-32777823 (0x1f42658-0x1f4265f)
>> 32777816*512=16782241792 Offset in H: (bytes)
>>
>> MICROS~1.TMP
>> a few hundred zeroes... This is NOT an XML file of
>> course. CoreIdleState::
>> clientStructs.cpp
>> SyncTelemetry
>> VolumeChangeNotification
>> MainThrhead Not a typo.
>>
>> File 247081
>> \found.000\dir0000.chk\0006.xml
>> $STANDARD_INFORMATION (resident)
>> $FILE_NAME (resident)
>> $DATA (nonresident)
>> logical sectors 32777848-32777855 (0x1f42678-0x1f4267f)
>>
>> File 247082
>> \found.000\dir0000.chk\0007.xml
>> $STANDARD_INFORMATION (resident)
>> $FILE_NAME (resident)
>> $DATA (nonresident)
>> logical sectors 32778536-32778543 (0x1f42928-0x1f4292f)
>>
>> File 247083
>> \found.000\dir0000.chk\0008.xml
>> $STANDARD_INFORMATION (resident)
>> $FILE_NAME (resident)
>> $DATA (nonresident)
>> logical sectors 32778544-32778551 (0x1f42930-0x1f42937)
>>
>> File 247088
>> \found.000\dir0000.chk\0009.xml
>> $STANDARD_INFORMATION (resident)
>> $FILE_NAME (resident)
>> $DATA (nonresident)
>> logical sectors 32778592-32778599 (0x1f42960-0x1f42967)
>>
>> File 247089
>> \found.000\dir0000.chk\0010.xml
>> $STANDARD_INFORMATION (resident)
>> $FILE_NAME (resident)
>> $DATA (nonresident)
>> logical sectors 32778600-32778607 (0x1f42968-0x1f4296f)
>>
>> File 247090
>> \found.000\dir0000.chk\0011.xml
>> $STANDARD_INFORMATION (resident)
>> $FILE_NAME (resident)
>> $DATA (nonresident)
>> logical sectors 32778608-32778615 (0x1f42970-0x1f42977)
>>
>> File 247091
>> \found.000\dir0000.chk\0012.xml
>> $STANDARD_INFORMATION (resident)
>> $FILE_NAME (resident)
>> $DATA (resident)
>>
>> File 247092
>> \found.000\dir0000.chk\0013.xml
>> $STANDARD_INFORMATION (resident)
>> $FILE_NAME (resident)
>> $DATA (nonresident)
>> logical sectors 32778616-32778623 (0x1f42978-0x1f4297f)
>>
>> File 247093
>> \found.000\dir0000.chk\0014.xml
>> $STANDARD_INFORMATION (resident)
>> $FILE_NAME (resident)
>> $DATA (nonresident)
>> logical sectors 32778624-32778631 (0x1f42980-0x1f42987)
>>
>> File 247094
>> \found.000\dir0000.chk\0015.xml
>> $STANDARD_INFORMATION (resident)
>> $FILE_NAME (resident)
>> $DATA (nonresident)
>> logical sectors 32778632-32778639 (0x1f42988-0x1f4298f)
>>
>> File 247095
>> \found.000\dir0000.chk\0016.xml
>> $STANDARD_INFORMATION (resident)
>> $FILE_NAME (resident)
>> $DATA (nonresident)
>> logical sectors 32778640-32778647 (0x1f42990-0x1f42997)
>>
>> File 247096
>> \found.000\dir0000.chk\0017.xml
>> $STANDARD_INFORMATION (resident)
>> $FILE_NAME (resident)
>> $DATA (resident)
>>
>> File 247097
>> \found.000\dir0000.chk\0018.xml
>> $STANDARD_INFORMATION (resident)
>> $FILE_NAME (resident)
>> $DATA (resident)
>>
>> File 247098
>> \found.000\dir0000.chk\0019.xml
>> $STANDARD_INFORMATION (resident)
>> $FILE_NAME (resident)
>> $DATA (resident)
>>
>> File 247099
>> \found.000\dir0000.chk\0020.xml
>> $STANDARD_INFORMATION (resident)
>> $FILE_NAME (resident)
>> $DATA (resident)
>>
>> File 247100
>> \found.000\dir0000.chk\0021.xml
>> $STANDARD_INFORMATION (resident)
>> $FILE_NAME (resident)
>> $DATA (resident)
>>
>> File 247101
>> \found.000\dir0000.chk\0022.xml
>> $STANDARD_INFORMATION (resident)
>> $FILE_NAME (resident)
>> $DATA (resident)
>>
>> File 247122
>> \found.000\dir0000.chk\0023.xml
>> $STANDARD_INFORMATION (resident)
>> $FILE_NAME (resident)
>> $DATA (resident)
>>
>> File 247123
>> \found.000\dir0000.chk\0024.xml
>> $STANDARD_INFORMATION (resident)
>> $FILE_NAME (resident)
>> $DATA (resident)
>>
>> File 247124
>> \found.000\dir0000.chk\0025.xml
>> $STANDARD_INFORMATION (resident)
>> $FILE_NAME (resident)
>> $DATA (resident)
>>
>> File 247125
>> \found.000\dir0000.chk\0026.xml
>> $STANDARD_INFORMATION (resident)
>> $FILE_NAME (resident)
>> $DATA (resident)
>>
>> File 247126
>> \found.000\dir0000.chk\0027.xml
>> $STANDARD_INFORMATION (resident)
>> $FILE_NAME (resident)
>> $DATA (resident)
>>
>> File 247127
>> \found.000\dir0000.chk\0028.xml
>> $STANDARD_INFORMATION (resident)
>> $FILE_NAME (resident)
>> $DATA (resident)
>>
>> File 247128
>> \found.000\dir0000.chk\0029.xml
>> $STANDARD_INFORMATION (resident)
>> $FILE_NAME (resident)
>> $DATA (resident)
>>
>> File 247129
>> \found.000\dir0000.chk\0030.xml
>> $STANDARD_INFORMATION (resident)
>> $FILE_NAME (resident)
>> $DATA (resident)
>>
>> File 247130
>> \found.000\dir0000.chk\0031.xml
>> $STANDARD_INFORMATION (resident)
>> $FILE_NAME (resident)
>> $DATA (resident)
>>
>> File 247131
>> \found.000\dir0000.chk\0032.xml
>> $STANDARD_INFORMATION (resident)
>> $FILE_NAME (resident)
>> $DATA (resident)
>>
>> File 247132
>> \found.000\dir0000.chk\0033.xml
>> $STANDARD_INFORMATION (resident)
>> $FILE_NAME (resident)
>> $DATA (nonresident)
>> logical sectors 32778648-32778655 (0x1f42998-0x1f4299f)
>>
>> File 247133
>> \found.000\dir0000.chk\0034.xml
>> $STANDARD_INFORMATION (resident)
>> $FILE_NAME (resident)
>> $DATA (nonresident)
>> logical sectors 32778656-32778663 (0x1f429a0-0x1f429a7)
>>
>> File 247134
>> \found.000\dir0000.chk\0035.xml
>> $STANDARD_INFORMATION (resident)
>> $FILE_NAME (resident)
>> $DATA (resident)
>>
>> File 247135
>> \found.000\dir0000.chk\0036.xml
>> $STANDARD_INFORMATION (resident)
>> $FILE_NAME (resident)
>> $DATA (resident)
>>
>> File 247136
>> \found.000\dir0000.chk\0037.xml
>> $STANDARD_INFORMATION (resident)
>> $FILE_NAME (resident)
>> $DATA (resident)
>>
>> File 247137
>> \found.000\dir0000.chk\0038.xml
>> $STANDARD_INFORMATION (resident)
>> $FILE_NAME (resident)
>> $DATA (resident)
>>
>> File 247138
>> \found.000\dir0000.chk\0039.xml
>> $STANDARD_INFORMATION (resident)
>> $FILE_NAME (resident)
>> $DATA (resident)
>>
>> File 247139
>> \found.000\dir0000.chk\0040.xml
>> $STANDARD_INFORMATION (resident)
>> $FILE_NAME (resident)
>> $DATA (nonresident)
>> logical sectors 32778664-32778671 (0x1f429a8-0x1f429af)
>>
>> File 247140
>> \found.000\dir0000.chk\0041.xml
>> $STANDARD_INFORMATION (resident)
>> $FILE_NAME (resident)
>> $DATA (nonresident)
>> logical sectors 32778672-32778679 (0x1f429b0-0x1f429b7)
>>
>> File 247141
>> \found.000\dir0000.chk\0042.xml
>> $STANDARD_INFORMATION (resident)
>> $FILE_NAME (resident)
>> $DATA (nonresident)
>> logical sectors 32778680-32778687 (0x1f429b8-0x1f429bf)
>>
>> File 247142
>> \found.000\dir0000.chk\0043.xml
>> $STANDARD_INFORMATION (resident)
>> $FILE_NAME (resident)
>> $DATA (resident)
>>
>> File 247143
>> \found.000\dir0000.chk\0044.xml
>> $STANDARD_INFORMATION (resident)
>> $FILE_NAME (resident)
>> $DATA (resident)
>>
>> File 247144
>> \found.000\dir0000.chk\0045.xml
>> $STANDARD_INFORMATION (resident)
>> $FILE_NAME (resident)
>> $DATA (nonresident)
>> logical sectors 32778688-32778695 (0x1f429c0-0x1f429c7)
>>
>> File 247145
>> \found.000\dir0000.chk\0046.xml
>> $STANDARD_INFORMATION (resident)
>> $FILE_NAME (resident)
>> $DATA (nonresident)
>> logical sectors 32778696-32778703 (0x1f429c8-0x1f429cf)
>>
>> File 247146
>> \found.000\dir0000.chk\0047.xml
>> $STANDARD_INFORMATION (resident)
>> $FILE_NAME (resident)
>> $DATA (nonresident)
>> logical sectors 32778704-32778711 (0x1f429d0-0x1f429d7)
>>
>> File 247147
>> \found.000\dir0000.chk\0048.xml
>> $STANDARD_INFORMATION (resident)
>> $FILE_NAME (resident)
>> $DATA (nonresident)
>> logical sectors 32778712-32778719 (0x1f429d8-0x1f429df)
>>
>> File 247148
>> \found.000\dir0000.chk\0049.xml
>> $STANDARD_INFORMATION (resident)
>> $FILE_NAME (resident)
>> $DATA (nonresident)
>> logical sectors 32778784-32778791 (0x1f42a20-0x1f42a27)
>>
>> File 247149
>> \found.000\dir0000.chk\0050.xml
>> $STANDARD_INFORMATION (resident)
>> $FILE_NAME (resident)
>> $DATA (nonresident)
>> logical sectors 32778792-32778799 (0x1f42a28-0x1f42a2f)
>>
>> File 247150
>> \found.000\dir0000.chk\0051.xml
>> $STANDARD_INFORMATION (resident)
>> $FILE_NAME (resident)
>> $DATA (nonresident)
>> logical sectors 32778800-32778807 (0x1f42a30-0x1f42a37)
>>
>> File 247151
>> \found.000\dir0000.chk\0052.xml
>> $STANDARD_INFORMATION (resident)
>> $FILE_NAME (resident)
>> $DATA (nonresident)
>> logical sectors 32778808-32778815 (0x1f42a38-0x1f42a3f)
>>
>> File 247156
>> \found.000\dir0000.chk\0054.xml
>> $STANDARD_INFORMATION (resident)
>> $FILE_NAME (resident)
>> $DATA (nonresident)
>> logical sectors 32779680-32779687 (0x1f42da0-0x1f42da7)
>>
>> Paul
>>
>>
>
> Directory entry shows zro length.
>

>>
>> Directory entry shows zro length.
>>
>
> I used nfi.exe to list the contents of the partition, and
> that's where the file entries come from. I use HxD hex editor
> to examine the entries, using their logical sector address
> and multiplying by 512 to get a byte address (that HxD uses).
>
> I may be able to get a File Explorer view of those, using
> a Macrium backup image of the partition. The Macrium mounter
> has a tick box to remove restrictions, which is handy at a time
> like this.
>
> This is what mine shows, when my backed-up OS partition is mounted
> as K: for a look (using a macrium.mrimg file).
>
> K:\found.000>dir /s # running cmd.exe as
> shell
> Volume in drive K is WIN10AMD
> Volume Serial Number is 80FF-1A62
>
> Directory of K:\found.000
>
> 12/05/2021 05:14 AM <DIR> dir0000.chk
> 0 File(s) 0 bytes <=== directory
> info is damaged
>
> Directory of K:\found.000\dir0000.chk
>
> 12/05/2021 05:14 AM <DIR> .
> 12/04/2021 11:05 PM 1,044 0005.xml
> 12/04/2021 11:05 PM 1,128 0006.xml
> 12/04/2021 11:05 PM 1,044 0007.xml
> 12/04/2021 11:05 PM 1,100 0008.xml
> 12/04/2021 11:06 PM 1,098 0009.xml
> 12/04/2021 11:06 PM 1,150 0010.xml
> 12/04/2021 11:06 PM 1,044 0011.xml
> 12/04/2021 11:06 PM 0 0012.xml
> 12/04/2021 11:06 PM 1,092 0013.xml
> 12/04/2021 11:06 PM 1,268 0014.xml
> 12/04/2021 11:06 PM 1,050 0015.xml
> 12/04/2021 11:06 PM 1,118 0016.xml
> 12/04/2021 11:06 PM 0 0017.xml
> 12/04/2021 11:06 PM 0 0018.xml
> 12/04/2021 11:06 PM 0 0019.xml
> 12/04/2021 11:06 PM 0 0020.xml
> 12/04/2021 11:06 PM 0 0021.xml
> 12/04/2021 11:06 PM 0 0022.xml
> 12/04/2021 11:06 PM 0 0023.xml
> 12/04/2021 11:06 PM 0 0024.xml
> 12/04/2021 11:06 PM 0 0025.xml
> 12/04/2021 11:06 PM 0 0026.xml
> 12/04/2021 11:06 PM 0 0027.xml
> 12/04/2021 11:06 PM 0 0028.xml
> 12/04/2021 11:06 PM 0 0029.xml
> 12/04/2021 11:06 PM 0 0030.xml
> 12/04/2021 11:06 PM 0 0031.xml
> 12/04/2021 11:06 PM 0 0032.xml
> 12/04/2021 11:06 PM 1,080 0033.xml
> 12/04/2021 11:06 PM 1,120 0034.xml
> 12/04/2021 11:06 PM 0 0035.xml
> 12/04/2021 11:06 PM 0 0036.xml
> 12/04/2021 11:06 PM 0 0037.xml
> 12/04/2021 11:06 PM 0 0038.xml
> 12/04/2021 11:06 PM 0 0039.xml
> 12/04/2021 11:06 PM 1,044 0040.xml
> 12/04/2021 11:06 PM 1,108 0041.xml
> 12/04/2021 11:06 PM 1,106 0042.xml
> 12/04/2021 11:06 PM 0 0043.xml
> 12/04/2021 11:06 PM 0 0044.xml
> 12/04/2021 11:06 PM 1,128 0045.xml
> 12/04/2021 11:06 PM 1,100 0046.xml
> 12/04/2021 11:06 PM 1,074 0047.xml
> 12/04/2021 11:06 PM 1,098 0048.xml
> 12/04/2021 11:06 PM 1,098 0049.xml
> 12/04/2021 11:06 PM 1,094 0050.xml
> 12/04/2021 11:06 PM 1,044 0051.xml
> 12/04/2021 11:06 PM 1,090 0052.xml
> 12/04/2021 11:11 PM 1,098 0054.xml
> 49 File(s) 27,418 bytes
>
> Total Files Listed:
> 49 File(s) 27,418 bytes
> 2 Dir(s) 85,450,399,744 bytes free
>
> So something happened back when the machine was relatively new.
>
> And the size really isn't zero, there's a bit of stuff there.
>
> My ability to work in there is pretty limited, as a lot
> of the metadata for "dir0000.chk" is damaged. I really have
> to copy all those shards out, into another directory, to work
> on them.
>
> Paul
>
>

I like to think I am a little smarter than the average bear, but I have
neer penetrated the murky depths to this level. Never had to before.

Given that all of my external drives are at least three years old, and
the drive in question threw a new bunch of 'found' files again I deided
to bite the bullet and just replace the drive. Unfortunarely this is an
external USB drive moving so the 1.5 gb of data looks like it will take a
good 10hrs, since I only have one USB 3 port on my laptop I am limited by
USB 2 speeds,which right now is about 30 MB/s. zzzzzz

On 3/6/2024 8:37 PM, MajorLanGod wrote:

> I like to think I am a little smarter than the average bear, but I have
> neer penetrated the murky depths to this level. Never had to before.
>
> Given that all of my external drives are at least three years old, and
> the drive in question threw a new bunch of 'found' files again I deided
> to bite the bullet and just replace the drive. Unfortunarely this is an
> external USB drive moving so the 1.5 gb of data looks like it will take a
> good 10hrs, since I only have one USB 3 port on my laptop I am limited by
> USB 2 speeds,which right now is about 30 MB/s. zzzzzz

There are various options.

In some cases, maybe a linear transfer is best (so the seek time isn't
an issue).

I would use gddrescue package on Linux and "ddrescue" instead of "dd",
because it tolerates CRC errors. That's assuming there is a CRC error problem.
That's a linear transfer method (but not particularly good).

If the ten hours is caused by seek time, something like a backup program,
can back up "clusters" in linear order. Again, this prevents seeks from
getting in the way of performance.

But at some point, the sheer amount of data has to be transferred,
so if it's 1.5TB of data or 1500GB, then at 30 seconds per GB,
that is 750 minutes or a bit more than 10 hours. Maybe closer to
12 hours. If you just do a "copy a b", then you're adding seek time to that.
And on damaged drives, things can slow down quite a bit (such that
USB2 is no longer the limitation).

If you did the transfer with Macrium as a backup utility, it could
bomb out on a CRC error. Only if the drive was known to not be
throwing CRC errors, would you try it exactly that way ("smart" backup).

If you did the transfer in a less efficient way like "ddrescue",
then it's not going to stop, but it's not going to be very
fast either. If this was a 2TB drive with 1.5TB of data, then you'd
pay an additional 30% time to do a "dd" style copy of the drive.
You can "dd" from drive to drive, or you can "dd" from a drive
to a .img file (an image of a disk drive).

If your eventual destination was something on the laptop, you could
always connect the USB drive to a USB3 equipped desktop, then set up
a file share on your laptop, and transfer at USB3 speed on the
desktop, and have, say, a 112MB/sec network transfer rate limitation
over Ethernet.

I've done at least one data retrieval over Ethernet before, at 112MB/sec,
instead of doing it over USB2.

When life gives you lemons, you pick the biggest juiciest lemon.

Paul

Paul <nospam@needed.invalid> wrote:

> MajorLanGod wrote:
>
>> ... Unfortunarely this is an external USB drive moving so the 1.5 gb
>> of data looks like it will take a good 10hrs, ... /
______________________________________________/
/
> ... so if it's 1.5TB of data or 1500GB, ...

Luckily it's only 1.5 *GB* of data, so not nearly as bad.

On 07/03/2024 01:37, MajorLanGod wrote:
>
> snip
>
> I like to think I am a little smarter than the average bear, but I have
> neer penetrated the murky depths to this level. Never had to before.
>
> Given that all of my external drives are at least three years old, and
> the drive in question threw a new bunch of 'found' files again I deided
> to bite the bullet and just replace the drive. Unfortunarely this is an
> external USB drive moving so the 1.5 gb of data looks like it will take a
> good 10hrs, since I only have one USB 3 port on my laptop I am limited by
> USB 2 speeds,which right now is about 30 MB/s. zzzzzz
>

I'm not smarter than the average bear but I do proof read what I've
written before sending.:)

--
Regards
wasbit

On 3/6/2024 9:30 PM, VanguardLH wrote:
> Paul <nospam@needed.invalid> wrote:
>
>> MajorLanGod wrote:
>>
>>> ... Unfortunarely this is an external USB drive moving so the 1.5 gb
>>> of data looks like it will take a good 10hrs, ... /
> ______________________________________________/
> /
>> ... so if it's 1.5TB of data or 1500GB, ...
>
> Luckily it's only 1.5 *GB* of data, so not nearly as bad.
>

Correlation. 10 hour estimate is closer to 1.5TB than 1.5GB.
So I autocorrected to 1.5TB .

Paul

wasbit <wasbit@nowhere.com> wrote:

> MajorLanGod wrote:
>
>> I like to think I am a little smarter than the average bear, but I have
>> neer penetrated the murky depths to this level. Never had to before.
>
> I'm not smarter than the average bear but I do proof read what I've
> written before sending.:)

Alas, when proofreading your own material, sometimes your eyes see what
you expect them to see. I've still missed goofs after reviewing my post
before submitting it. Then, if I later look at my post after submission
to see mistakes, I have to submit a correction.

On 3/6/24 01:36, wasbit wrote:
> On 05/03/2024 06:51, T wrote:
>> snip <
>>
>> And if you constantly get a lot of those found xx files,
>> you may have a disk that is degrading.
>>
>> gsmartcontrol is a good way to check:
>> http://gsmartcontrol.sourceforge.net/home/index.php/Downloads
>>
>
> Thanks. Forgot I had this.
> Doesn't find my Windows NVMe drive (Samsung 960 EVO)

I should. But that being the case, install Samsung
Magician. It will give you health too.

https://semiconductor.samsung.com/consumer-storage/support/tools/

> but does find a
> second NVMe drive.
> When updating the Installer asks to remove old version before installing
> the new.
>

On 3/6/24 02:02, Paul wrote:
> Sample of the contents of a Found entry.
>
> When CHKDSK finds these, it appears to be using the
> "first available filenum slot" to create the linkage
> so that the clusters won't be lost. For the resident
> ones, it presumably copies the $MFT slot to this new
> location. Typically, the ones below might use one cluster
> (8 sectors, 4096 bytes per cluster standard). "Resident"
> means the ~700 byte storage area of an MFT 1KB slot.
>
> Using the logical sector number, and your hex editor,
> you could visit the cluster in question, and see
> what is in there. I dumped a bit of a dir entry and
> one "cluster" entry found.
>
> File 19
> \found.000
> $STANDARD_INFORMATION (resident)
> $FILE_NAME (resident)
> $INDEX_ROOT $I30 (resident)

Hi Paul,

I know that NTFS has journaling, but don't know how
it works. Are there any file s like this when
NTFS journals?

-T

On 3/8/2024 2:57 AM, T wrote:
> On 3/6/24 02:02, Paul wrote:
>> Sample of the contents of a Found entry.
>>
>> When CHKDSK finds these, it appears to be using the
>> "first available filenum slot" to create the linkage
>> so that the clusters won't be lost. For the resident
>> ones, it presumably copies the $MFT slot to this new
>> location. Typically, the ones below might use one cluster
>> (8 sectors, 4096 bytes per cluster standard). "Resident"
>> means the ~700 byte storage area of an MFT 1KB slot.
>>
>> Using the logical sector number, and your hex editor,
>> you could visit the cluster in question, and see
>> what is in there. I dumped a bit of a dir entry and
>> one "cluster" entry found.
>>
>> File 19
>> \found.000
>>      $STANDARD_INFORMATION (resident)
>>      $FILE_NAME (resident)
>>      $INDEX_ROOT $I30 (resident)
>
>
> Hi Paul,
>
> I know that NTFS has journaling, but don't know how
> it works.  Are there any file s like this when
> NTFS journals?
>
> -T

They could be created during journal playback (boot time), or
maybe they could be created during a CHKDSK run ? Windows has
"Robust NTFS", which includes background operations for integrity
checks. This was supposed to reduce the need for explicit CHKDSK and
reduce latent errors (the "collecting" of errors until things
are a mess and CHKDSK can't do a good job of untangling them).

I find it kinda strange, that they've been assigned
a file extension of .xml , as I don't think the process
did that in WinXP days. According to Google, if CHKDSK did it,
the fragments have a file extension of .chk .

By assigning the fragments filenum, that "preserved" the
clusters and also prevents the clusters from being reused.
But it's not for the same reason as the sparse $BADCLUS
prevents defective clusters from being used at the NTFS level.

Apparently there's two kinds of journal at work. Windows
has a "Change Journal", which is what the Search Indexer
would register for, and what Everything.exe would use to
keep its file lists up to date. The Change Journal for example,
announces to interested programs that "C:\a\b\d\e\filename.ext
has been deleted", and by being event based, the tools
listening in, don't have to "scan" volumes constantly to
detect changes.

Whereas the other journal information that is collected,
allows cleanup operations at boot time. The operation done
at that time, can tell whether a fragment should have been
committed (officially marked as a file in $MFT), or the
fragment should be discarded (because it wasn't committed).
But exactly how such a playback journal works, or what
its outputs are, I haven't read anything about that.

Windows has the Dirty bit, to signal that CHKDSK should
definitely be run (used by Linux), the playback journal is
a way of "discovering" a file system has a minor problem.
And playback is mostly going to respond, by "giving the
odd thing a snip". I don't know if there is any mechanism
for a playback issue, to trigger an actual CHKDSK, because
usually CHKDSK asks for user confirmation.

Even if NTFS was documented, I doubt we'd get that sort of
detail (how the moving parts work). A forensics
person would know more about this, than most other kinds
of people. And a Google isn't yielding any forensics hits
right now.

Paul

MajorLanGod <lonelydad58@gmail.com> wrote:

> Paul <nospam@needed.invalid> wrote:
>
>> MajorLanGod wrote:
>>
>>> Fully updated Windows11. Once in a while I find some 'Fond nn' zero
>>> length files in a directory. No problems from deleting them. Any
>>> idea where they are coming from and/or why?
>>
>> Sample of the contents of a Found entry.
>>
>> When CHKDSK finds these, it appears to be using the
>> "first available filenum slot" to create the linkage
>> so that the clusters won't be lost. For the resident
>> ones, it presumably copies the $MFT slot to this new
>> location. Typically, the ones below might use one cluster
>> (8 sectors, 4096 bytes per cluster standard). "Resident"
>> means the ~700 byte storage area of an MFT 1KB slot.
>>
>> Using the logical sector number, and your hex editor,
>> you could visit the cluster in question, and see
>> what is in there. I dumped a bit of a dir entry and
>> one "cluster" entry found.
>>
>> File 19
>> \found.000
>> $STANDARD_INFORMATION (resident)
>> $FILE_NAME (resident)
>> $INDEX_ROOT $I30 (resident)
>> ...
>
> Directory entry shows zro length.

You see a \found.000 folder (directory), but no .chk files in it? When
CHKDSK detects bad sectors, it marks them as unusable. Any files that
encompassed those bad sectors get deleted, but CHKDSK attempts to grab
fragments to store in the .chk files.

https://www.partitionwizard.com/disk-recovery/recover-files-from-found000-folder.html

The \found.000 folder wouldn't exist unless some .chk files had been
stored there from a prior CHKDSK run. If you run cleanup tools, they
could delete the .chk files but leave the found.000 folder.

For example, I use CCleaner which has an option (selected by default) to
delete "Chkdsk file fragments". I don't have any .chk files nor the
found.000 folder, so I cannot test if CCleaner just deletes the .chk
files in the folder, or deletes the entire folder hence taking the .chk
files with the folder delete.

When you did see the found.000 folder, and before you deleted any files
within, and hopefully before any cleanup tool gets run, where there .chk
files in that folder? You before said you found them. At that time the
folder should not be empty. By "zero length" are you talking about
nothing in the folder, or something reporting zero for the folder?
Found.000 is a hidden system folder.

You say you saw "fond nn" zero-length files in an unidentified folder.
Was "found nn" the actual filenames? I think respondents figured the
unidentified folder was \Found.00* (there could be more than the .000
folder) which would have .chk files within unless those folders got
cleaned out. But maybe you did see files named "fond nn" or "found nn"
(fond or found, a space, and a 2-digit number) in some other folder.
Please clarify. We might be going off on a tangent by assuming you
meant to say something else. Knowing exactly what the files were named,
and exactly which folder, are important details, as winston alluded. If
the files are named "found nn" (with nn a 2-digit number) and *not* in a
Folder.00* named folder, you have some program generating those files,
and not something caused by CHKDSK.

Paul <nospam@needed.invalid> wrote in news:uscfkm$12j8m$2@dont-email.me:

> On 3/6/2024 9:30 PM, VanguardLH wrote:
>> Paul <nospam@needed.invalid> wrote:
>>
>>> MajorLanGod wrote:
>>>
>>>> ... Unfortunarely this is an external USB drive moving so the 1.5 gb
>>>> of data looks like it will take a good 10hrs, ... /
>> ______________________________________________/
>> /
>>> ... so if it's 1.5TB of data or 1500GB, ...
>>
>> Luckily it's only 1.5 *GB* of data, so not nearly as bad.
>>
>
> Correlation. 10 hour estimate is closer to 1.5TB than 1.5GB.
> So I autocorrected to 1.5TB .
>
> Paul
>

So I mixed up my acronymns. It till took forever!

On 3/8/2024 7:36 PM, MajorLanGod wrote:
> Paul <nospam@needed.invalid> wrote in news:uscfkm$12j8m$2@dont-email.me:
>
>> On 3/6/2024 9:30 PM, VanguardLH wrote:
>>> Paul <nospam@needed.invalid> wrote:
>>>
>>>> MajorLanGod wrote:
>>>>
>>>>> ... Unfortunarely this is an external USB drive moving so the 1.5 gb
>>>>> of data looks like it will take a good 10hrs, ... /
>>> ______________________________________________/
>>> /
>>>> ... so if it's 1.5TB of data or 1500GB, ...
>>>
>>> Luckily it's only 1.5 *GB* of data, so not nearly as bad.
>>>
>>
>> Correlation. 10 hour estimate is closer to 1.5TB than 1.5GB.
>> So I autocorrected to 1.5TB .
>>
>> Paul
>>
>
> So I mixed up my acronymns. It till took forever!
>

I have one computer here, that they only put USB 1.1 on it,
to make another standard "look better". I think I actually
did copy some data one day with it, so it didn't stay entirely
unused. The USB1.1 has a practical transfer rate of 1 megabyte per second.

The fastest interface it had, was the network connection. And I
actually FTP transferred data, to get the fastest rate possible.
USB was 1MB/sec. Firewire was 30MB/sec. Ethernet was 112MB/sec.
So at least they didn't skimp on Ethernet.

Paul

On 3/8/24 02:25, Paul wrote:

Thank you for the explanation!

> Windows has the Dirty bit, to signal that CHKDSK should
> definitely be run (used by Linux)

And Linux won't let you mount it until you go
back into Windows and run chkdsk (Windows will at
boot up time). It is especially annoying when
you have just altered the partitions with gparted.

But the cleaver Linux guy can get around the
dirty bit inside Linux which:

To fix a dirty flag on NTFS:
# ntfsfix -d device (/dev/sda1)
"#" means as root.