Immediate Save To Disk

[highend]

You really change your Favorites that often that this would be a concern?

This isn't it. It's about me not wanting XY to save the configuration (options) together with
changed favorites at the same time. My XY configuration is 99% static (and very well documented)
while my favorites change every few days (e.g when I'm working on a small helper tool, that I
post here (like two times in the last seven? days).

[admin]

1) Extend the "Favorites" category to include "Favorites, Custom File Icons, and Custom File Associations" AND have all this in separate file "Favs.ini" (I think this kind of makes sense conceptually). These are all actively made settings (not just MRU lists) AND they are not done in "Configuration" (F9).

Not now. Needs more thinking. The consequences are vast, functionally and in terms of support.

[Filehero]

This is very helpful feature! Especially for cases, when XYplorer crashes (a very, very rare event) or XYplorer gets suddenly killed (son pushing the power switch - happens much more often )

However, every once in a while I need to start a new/second instance that does not change the existing configuration at all. Before this feature I was simply trying to exit XYplorer without saving. Currently, I have minimized the risk by applying Immediate Save to everything but Configuration.

I wish the would be another, more straightforward way to make the settings read-only (besides script-based mangling of temporary XYplorer.inis)?
I'm thinking of
- a new option for SC setting(p)
- or a new Command Line Switch special value /ini=readonly

Is there any other existing way to have the same?

FH

[highend]

Start it with a script that sets the read only attribute?

[Filehero]

Start it with a script that sets the read only attribute?

You mean on XYplorer.ini?

[highend]

Yep

[Filehero]

Wouldn't this require to undo the read-only flag on the file system prior to use XYplorer "normally"?

[jupe]

I know you said you didn't want script based wrangling of temp ini files but to me it seems like the best solution currently.

Something similar to this where you always use the same temp file seems pretty straightforward:

Code: Select all

	new("%TEMP%\XYPlorer.ini", "file", "<xydata>\XYplorer.ini");
	run("""<xypath>\XYPlorer.exe"" /ini=""%TEMP%\XYPlorer.ini"" /title=""TEMPORARY""");
	
	// OR
	
	new("%TEMP%\XYPlorer.ini", "file", "<xydata>\XYplorer.ini");
	loadsettings "%TEMP%\XYPlorer.ini", 1;

Sorry, I realize it's not what you asked for.

[highend]

Wouldn't this require to undo the read-only flag on the file system prior to use XYplorer "normally"?

Sure, but I use Find and Run Robot and I have shortcuts for such operations so I just type
xyw
for a write protected version
or
xyn
to remove the read only attribute
etc.

[jupe]

I just had another thought about this, I am not sure if it would work, and am no expert, just throwing it out there if you are interested, although you are probably more looking for a native solution.

Could you run XY as a different user (using Microsofts PSExec or alternatives) something like

psexec -u username -p password XYplorer.exe

and then make sure that user doesn't have write privileges to the ini file or the data folder.

[admin]

- or a new Command Line Switch special value /ini=readonly

Looks good to me. Or rather like this: /readonly

Would it be enough to auto-untick these two when the readonly switch is passed?
Configuration | Startup & Exit | Save Settings | Save settings on exit
Configuration | Startup & Exit | Save Settings | Save changes to disk immediately

[klownboy]

This question doesn't affect me anymore, but would this change for a /readonly switch prevent a child from saving a bad configuration by inadvertently or purposely pressing the save toolbar button (i.e., would it affectively disable the save button)? It might be of value to a parent.

[Filehero]

@Don: yes! I think this should prevent accidental config overwrites.

Thank you.

[admin]

This question doesn't affect me anymore, but would this change for a /readonly switch prevent a child from saving a bad configuration by inadvertently or purposely pressing the save toolbar button (i.e., would it affectively disable the save button)? It might be of value to a parent.

No, it would not.

@Filehero: What would you think of a "hard read-only" (that makes it totally impossible to change any settings on disk)? I personally would find this the more interesting way to go. Similar like with "fresh;" it would have [READONLY] printed in the window title. Hey, I could even add a scripting command "readonly;" (and "readonlyhere;" analog to "freshhere;") that starts a new readonly instance.

[Filehero]

@Filehero: What would you think of a "hard read-only" (that makes it totally impossible to change any settings on disk)?

This is what I'm really after. Technically defeat any unwanted changes (be it caused by chrildren, too much wine or whatever...)