Everything.exe getting initialized by wrong Everything.ini

[hardik]

I have Everything.exe and Everything.ini under the same directory and I have also modified Everything.ini as per my use case such as setting "index_folder_size" set to 1 contrary to 0 in the original. As a result, Everything.exe gets initialized from the updated Everything.ini. However, sometimes, Everything.exe gets initialized by the outdated Everything.ini (present in my file system in some other directory) even though the path to the modified Everything.ini is explicitly given for the Everything.exe to start up.

[therube]

Do a search for:

everything .ini

.

You may have more then one, the one in the same directory as Everything.exe may or may not be what is associated with the Everything instance you are running.

See... Tools | Options | General -> Store settings and data in %APPDATA%\Everything.

If that is enabled, then that is where Everything is storing things.
Uncheck that, & it should then pick things up from the same directory where Everything.exe is.

[hardik]

I have not installed Everything search utility. I am just running the utility using the "Everything.exe -startup" command and exiting the same using the "Everything.exe -exit" command. This will not create an Everything.ini file in the "%APPDATA%\Everything" location, isn't that correct?

[therube]

I'm thinking, that if Everything is already running...

Everything -startup will use the existing instance (& the existing everything.ini that is being used by that instance).

If you use a named instance, that would create .ini, .db in the same location as Everything.exe

Code: Select all

Everything  -instance NEW1  -startup
Everything  -instance NEW1  -exit

(I don't use the installer version, & above is the results I see.)

[hardik]

I never keep Everything.exe always running in background. Whenever I need it, I run it in background using the startup command and then use the CLI (es.exe) to fetch the results. Once the job is done, I make sure that I exit the utility.

I am considering options. Is it possible to rename Everything.ini file (let's say FileSystemSearch.ini) that will allow Everything.exe to get initialized by this newly named ini? If yes, will that solve the problem of Everything.exe starting up using other/outdated ini files in the file system?

[void]

even though the path to the modified Everything.ini is explicitly given for the Everything.exe to start up.

How are you doing this? -with the -ini command line option?
Are you running Everything.ini from multiple locations? Only one instance of Everything can run at a time.

This will not create an Everything.ini file in the "%APPDATA%\Everything" location, isn't that correct?

This is true for the portable version.
The ini setting app_data in the Everything.ini in the same location as your Everything controls this setting.
If this setting is not present or set to 0, all your settings are stored in the Everything.ini in the same location as your Everything.exe.

I am considering options. Is it possible to rename Everything.ini file (let's say FileSystemSearch.ini) that will allow Everything.exe to get initialized by this newly named ini? If yes, will that solve the problem of Everything.exe starting up using other/outdated ini files in the file system?

Try setting your Everything.ini to read-only
Everything will never modify a read-only Everything.ini.

or

Copy your pre-set Everything.ini over your Everything.ini before running Everything.exe.

[hardik]

How are you doing this? -with the -ini command line option?
Are you running Everything.ini from multiple locations? Only one instance of Everything can run at a time.

I have Everything.exe and Everything.ini under the same directory. I have written code to start Everything.exe from that directory using the startup command and assumed it to get initialized through the ini, which is already present under the same directory.

If this setting is not present or set to 0, all your settings are stored in the Everything.ini in the same location as your Everything.exe.

I do not have this setting in the ini.

[therube]

I have Everything.exe and Everything.ini under the same directory

How are you invoking Everything.exe?
If by way of a relative path to Everything.exe, then the .db .ini will created where Everything.exe resides & not where it was invoked from.

Say you have (an) Everything.exe is at C:/bin/everything.exe.

And you are sitting in C:/tmp/dumy/.
You also have (another) Everything.exe in C:/tmp/dumy/Everything.exe.

If you run from a command line (or batch file), c:/bin/everything.exe -startup, the .ini from c:/bin/ will be used - even if you happened to be in the C:/tmp/dumy directory. (If from that /dumy/ directory you simply ran, Everything.exe -startup [using the Everything.exe that resides there], or c:/tmp/dumy/Everything.exe -startup, then the .ini in C:/tmp/dumy should be used.)

[hardik]

I have a C# application that is installed in "C:\\ProgramFiles\\MyProject\\MyApplication.exe" location which calls the Everything.exe present in the location "C:\\ProgramData\\MyProject\\Binaries\\Everything.exe". The same location also has the Everything.ini and es.exe as well. Please find below the code that calls Everything.exe for starting up

Code: Select all

ProcessStartInfo startInfo = new ProcessStartInfo
{
	WindowStyle = ProcessWindowStyle.Hidden,
	FileName = "C:\\ProgramData\\MyProject\\Binaries\\Everything.exe"
	Arguments = "-startup"
};
process.StartInfo = startInfo;
process.StartInfo.UseShellExecute = false;
process.StartInfo.RedirectStandardOutput = true;
process.Start();

Once Everything is up and running, calls are made to get the es.exe output as shown below.

Code: Select all

ProcessStartInfo startInfo = new ProcessStartInfo
{
	WindowStyle = ProcessWindowStyle.Hidden,
	FileName = "C:\\ProgramData\\MyProject\\Binaries\\es.exe"
	Arguments = "parent:\"C:\" -size -full-path-and-name -attributes"
};
process.StartInfo = startInfo;
process.StartInfo.UseShellExecute = false;
process.StartInfo.RedirectStandardOutput = true;
process.Start();

Please let me know if this is the correct way because I observed that it ends picking up the outdated ini file and not the latest ini file present in the above mentioned location.

[therube]

Is it possible to rename Everything.ini file (let's say FileSystemSearch.ini) that will allow Everything.exe to get initialized by this newly named ini?

Code: Select all

C:\DEV\Everything.exe  -startup  -instance test123  -config configgg.ini

With that, configgg.ini is "relative".
It will be saved in whatever directory the Everything command was run from.

You can use a path with -config, C:\DEV\configgg.ini.

But then you have to figure where the .db is coming from, which by default (in my scenario) in C:\DEV\.
(Not sure offhand if -db can also be used with a path?)

[therube]

I have written code to start Everything.exe from that directory using the startup command and assumed it to get initialized through the ini, which is already present under the same directory.

Hmm ?

I have a C# application that is installed in "C:\\ProgramFiles\\MyProject\\MyApplication.exe" location which calls the Everything.exe present in the location "C:\\ProgramData\\MyProject\\Binaries\\Everything.exe". The same location also has the Everything.ini and es.exe as well. Please find below the code that calls Everything.exe for starting up

"same location"

Which location is that; /MyProject/ or /MyProject/Binaries/ ?

I would expect, by default, that the .ini that would be used would be the one in /MyProject/.

Everything.exe gets initialized by the outdated Everything.ini (present in my file system in some other directory)

Where specifically is that "other directory"?

[hardik]

Which location is that; /MyProject/ or /MyProject/Binaries/ ?

MyProject/Binaries/Everything.ini

Where specifically is that "other directory"?

I can not recollect exactly but I guess it was under "C:\Users\Username\AppData\..." folder or some other folder. After that, I deleted all the Everything.ini from my file system (except the one in the location MyProject/Binaries/Everything.ini) and then tried starting up Everything.exe again. This time, it got initialized with the correct one.