Strange bug with disk free space

[0xDEADC0DE]

When I'm running Everything, it happens very often that when I move a file from one disk to another, the file gets deleted after the move, but the disk free space is not updated. I have to run chkdsk to get the correct free space. As long as I don't have the correct free space, the disk is full and I cannot copy or extract files on it.
When I close Everything, nothing changes. I have to run chkdsk to fix it. It's a NTFS drive.
I haven't had any problem with 1318a and I cannot remember to have a problem with 1339a.
But with 1349a, 1354a and 1355a I have this strange problem.
The drive is an internal m2 SSD: Intel 960p.
The settings I have checked:
- Include in database
- Enable USN Journal
Maximum size: 32768
Allocation delta: 8192
- Load USN Journal into the Recent Changes database
- Monitor changes

I'm using Windows 11 and doing most file transfers with Total Commander and integration with Everything enabled.

Anybody else here who has this strange problem?

[void]

Some ideas:

Disable volume change detection:

• In Everything 1.5, from the Tools menu, click Options.
• Click the Advanced tab on the left.
• To the right of Show settings containing, search for:
  volume
• Select check_for_volume_change_on_computer_change.
• Set the value to: false
• Click OK.

A recent feature was added to detect changes to volume properties.
Everything will only gather volume properties when a volume property is shown or you are searching for a volume property.
There might be a shell extension holding onto a volume handle..



Disable read_ntfs_file_record retry:

• In Everything 1.5, from the Tools menu, click Options.
• Click the Advanced tab on the left.
• To the right of Show settings containing, search for:
  ntfs
• Select get_ntfs_file_record_retry_timeout.
• Set the value to: 0
• Click OK.

A recent feature was added to re-read fragmented file records when they are out of sync.
Everything might be getting stuck re-reading these fragmented file records forever..



Please let me know if these help or if the issue persists.

[0xDEADC0DE]

I have changed the settings and I will report back the next days if it worked.

[therube]

I have to run chkdsk to get the correct free space.

Does CHKDSK report any issues?

[0xDEADC0DE]

Does CHKDSK report any issues?

No, but as soon as I run it, I get the correct result for disk free space.

[0xDEADC0DE]

It looks like it's working.
What disadvantages do I have with these settings set to false and 0?

[0xDEADC0DE]

Nope, didn't work.

Code: Select all

[2023-09-04 23:47:23,52] C:\Windows\System32> chkdsk b:
The type of the file system is NTFS.
Volume label is Intel 960p 2 TB NTFS.

WARNING!  /F parameter not specified.
Running CHKDSK in read-only mode.

Stage 1: Examining basic file system structure ...
  293888 file records processed.
File verification completed.
 Phase duration (File record verification): 4.37 seconds.
  1239 large file records processed.
 Phase duration (Orphan file record recovery): 1.11 milliseconds.
  0 bad file records processed.
 Phase duration (Bad file record checking): 0.40 milliseconds.

Stage 2: Examining file name linkage ...
  4128 reparse records processed.
  336298 index entries processed.
Index verification completed.
 Phase duration (Index verification): 4.43 seconds.
  0 unindexed files scanned.
 Phase duration (Orphan reconnection): 99.60 milliseconds.
  0 unindexed files recovered to lost and found.
 Phase duration (Orphan recovery to lost and found): 0.38 milliseconds.
  4128 reparse records processed.
 Phase duration (Reparse point and Object ID verification): 45.84 milliseconds.

Stage 3: Examining security descriptors ...
Security descriptor verification completed.
 Phase duration (Security descriptor verification): 12.66 milliseconds.
  21206 data files processed.
 Phase duration (Data attribute verification): 0.92 milliseconds.
CHKDSK is verifying Usn Journal...
  36633648 USN bytes processed.
Usn Journal verification completed.
 Phase duration (USN journal verification): 185.10 milliseconds.

Windows has scanned the file system and found no problems.
No further action is required.

2000380927 KB total disk space.
1818071280 KB in 224495 files.
     61708 KB in 21207 indexes.
         0 KB in bad sectors.
    457223 KB in use by the system.
     65536 KB occupied by the log file.
 181790716 KB available on disk.

      4096 bytes in each allocation unit.
 500095231 total allocation units on disk.
  45447679 allocation units available on disk.
Total duration: 9.16 seconds (9160 ms).

[2023-09-04 23:48:34,73] C:\Windows\System32>

As soon as I type chkdsk and this line appears "The type of the file system is NTFS.", the free space is correct. I don't need to wait until chkdsk finishes.

[void]

Another thought...

get_ntfs_file_record_retry_timeout is ignored if you are using the Everything Service.

Please try temporarily disabling monitoring for this drive and see if the issue persists:

• In Everything, from the Tools menu, click Options.
• Click the NTFS tab on the left.
• Select your b: drive.
• Uncheck Monitor changes.
• Click OK.

While monitor changes is temporarily disabled, to manually update the index in Everything of your drive:

• Type in the following search:
  /reindex b:
• Press ENTER in the search box.

Please let me know if this helps or if the issue persists.

[0xDEADC0DE]

I don't use the service. I use the portable zip

[therube]

I don't use the service. I use the portable zip

They're not exclusive.
Help | Troubleshooting, will show something like: Service: 1 (connected / installed and running), if you're using the Service.

[0xDEADC0DE]

Code: Select all

Everything:	1.5.0.1355a (x64)
OS:	Windows NT 10.0 22621 (x64)
Admin:	1
Service:	0 (disconnected / not installed)
Command line:	-isrunas -startup
Binary:	C:\USB\Software\Important\Everything-1.5.0.1355a.x64\Everything64.exe
Profile:	C:\USB\Software\Important\Everything-1.5.0.1355a.x64\Everything.ini
Database:	C:\USB\Software\Important\Everything-1.5.0.1355a.x64\Everything.db
Config:	run_as_admin=1
Config:	alpha_instance=0
Config:	match_path=1
Config:	match_diacritics=1
Config:	hide_empty_search_results=1
Config:	auto_remove_offline_ntfs_volumes=1
Config:	auto_include_fixed_refs_volumes=1
Config:	auto_remove_offline_refs_volumes=1
Config:	auto_include_fixed_fat_volumes=1
Config:	auto_remove_offline_fat_volumes=1
Config:	size_format=1
Config:	index_date_created=1
Config:	fast_date_created_sort=1
Config:	index_date_accessed=1
Config:	fast_date_accessed_sort=1
Config:	index_attributes=1
Config:	fast_attributes_sort=1
Config:	fast_extension_sort=1
Config:	index_recent_changes=1
Config:	content_buf_size=0
Config:	filter=EVERYTHING
Config:	search_history_enabled=0
Config:	plugins=0
Config:	ntfs_volumes=[{"path":"B:","volume_name":"\\\\?\\Volume{16...8d}","monitor":0,"load_recent_changes":1},{"path":"C:","volume_name":"\\\\?\\Volume{11...63}","load_recent_changes":1},{"path":"E:","volume_name":"\\\\?\\Volume{6e...b0}","load_recent_changes":1}]

[void]

A big ask...

Could you please try versions 1340a..1348a.

Which is the first version causing the issue?

[0xDEADC0DE]

I will start with 1435a and check it and then go forward or backward

[void]

Thank you.

A binary search.. smart.

[0xDEADC0DE]

1345a showed the problem with a small test but not with the usual problem.
I "lost" only about 8 GB of free space instead of the usual 90 GB. I will try now 1340a

[0xDEADC0DE]

1340a is same like 1345a for me.

[void]

Thank you for checking 1340.

I haven't found any changes from 1339 -> 1340 that could cause this issue.



Are you showing the preview pane?
-There's a few changes to how previews are rendered, maybe a preview host is causing the issue...

[0xDEADC0DE]

I don't use the preview pane.

I will try older versions now. Perhaps there was also the problem but loosing only a few GB wasn't obvious compared to 90 GB with the new versions 1349a+ I've had used.