Image of system created outside of Windows and saved to root folder escapes indexation

[Thy Grand Voidinesss]

I just experienced something peculiar

When using for the 123th time in this decade Acronis True Image 2021 from a bootable DVD, I created image of my system - but this time I created the TIBX files to main folders of 3 different drives, instead as usual to some subfolders. And all 3 were not indexed by Everything - until I took ownership with Access Control List. It was also then that they became available for e.g. renaming in Windows Explorer

Chat GPT is giving me a detailed explanation, as to how it is not a bug but an edge case scenario when handling NTFS volumes in Pre-boot environment - but the explanations are above my computer knowledge and I do not trust this flip flopping machine

So: is it not a fault of Everything; and there is nothing that this great program can do on its own to see such files? I am asking because it took my a while to find them, because I was looking for them via Everything after few hours after their creation and simply forgotten that I used roots as paths instead of nested folders


I am using Everything 1.5.0.1404a x64 Portable on Windows 10 IOT Enterprise LTSC 21H2 x64 [19044.6575]

[void]

Sounds like the tibx file was not logged to the USN Journal.

Please check what was logged in your USN Journal with dumpusn:

• From an admin command prompt, run:
  
  dumpusn "c:\my image.tibx"
• What is shown in the output?

[Thy Grand Voidinesss]

Within a week or two I should be making a new image, so I will gladly perform tests then and report back with findings

[Thy Grand Voidinesss]

I get

Z:\>dumpusn "Z:\MyBackup.tibx"
'dumpusn' is not recognized as an internal or external command,
operable program or batch file.

in CMD and

PS Z:\> dumpusn "Z:\MyBackup.tibx"
dumpusn: The term 'dumpusn' is not recognized as a name of a cmdlet, function, script file, or executable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

in PowerShell Core 7.5.4 Portable

[therube]

The file, dumpusn.exe, would need to either be at Z:\ or within a location in your PATH.

C:\> ECHO %PATH%

If not you need to provide the full path to dumpusn.exe.

C:>\downloads (or whereveritmaybe)\dumpusn.exe "Z:\MyBackup.tibx"

[Thy Grand Voidinesss]

But of course; and I did not download the

dumpusn.exe

before, cause I automatically assumed it was some Microsoft tool built-in to Windows and missed the provided link. Stupid me, reading posts being half asleep


Now in CMD what I get

Code: Select all

Z:\>dumpusn "Z:\MyBackup.tibx"

Z:\>dumpusn "Z:\dumpusn.exe"
FILE_CREATE 0x0005000000000005 dumpusn.exe
DATA_EXTEND|FILE_CREATE 0x0005000000000005 dumpusn.exe
DATA_OVERWRITE|DATA_EXTEND|FILE_CREATE 0x0005000000000005 dumpusn.exe
DATA_OVERWRITE|DATA_EXTEND|FILE_CREATE|BASIC_INFO_CHANGE 0x0005000000000005 dumpusn.exe
DATA_OVERWRITE|DATA_EXTEND|FILE_CREATE|BASIC_INFO_CHANGE|CLOSE 0x0005000000000005 dumpusn.exe

Z:\>dumpusn "Z:\fake path due to non-existing file.test"
Error 2: unable to get FRN from filename.

Z:\>

As you can see, the TIBX is silently ignored, despite the EXE being able to report about itself

And after another Take Ownership action I get

Code: Select all

Z:\>dumpusn "Z:\MyBackup.tibx"
SECURITY_CHANGE 0x0005000000000005 MyBackup.tibx
SECURITY_CHANGE|CLOSE 0x0005000000000005 MyBackup.tibx
SECURITY_CHANGE 0x0005000000000005 MyBackup.tibx
SECURITY_CHANGE|CLOSE 0x0005000000000005 MyBackup.tibx

[void]

Thank you for the dumpusn output.

I suspect Acronis True Image is creating the file directly on the raw NTFS volume.
There's nothing logged to the USN Journal.

Since there's nothing written to the USN Journal, Everything will miss changes to this file.

[Thy Grand Voidinesss]

And it is not feasible for Everything to be upgraded with some another background monitoring process, that would look for such potential invisible-to-its-main-scanning-feature files - for the purpose of comparing them against main / current scanning results? FreeCommander, Double Commander, Windows Explorer - they all seem to be able to find such files without a sweat

Or is it doable, but it is such edge case scenario, that the time needed for implementation of this would not be rewarded by the gained niche feature?

[void]

There's no way to do this efficiently and without all sorts of sync issues.



To detect changes to tibx file, you could index your NTFS volume as a folder index under Tools -> Options -> Folders (instead of Tools -> Options -> NTFS)

However, it would be very slow at indexing and inefficient at keeping your index up to date.

[void]

Since the file is created outside of Windows, consider running a script on startup to touch the file.

eg: Add and remove the read-only flag.

[Thy Grand Voidinesss]

Thank you for the suggestion

But in regards to how this partial invisibility is experienced by me - this is something I can simply avert by saving images of system not to root folders

But nevertheless I wanted to bring up this edge case scenario of mine to your attention - because I do not know if other user / programs can also create such invisible to Everything files and thus how niche or profound this issue might be in overall