FastCopy INI-file location

[aleek...@gmail.com]

Hello!

Thank you so much for your wonderful software.

Since I completely stucked with default behavior of ini-file location, decided to ask here.

I use fastcopy as copy utility in my command line scripting, and noticed that sometimes FastCopy leaves it's INI-file in user %AppData% folder no matter it's [FastCopy2.ini] with EXE or not.

So the exact situation is...

Having files in same folder:

[fastcopy.exe]

[FastCopy2.ini]

I run [fastcopy.exe] from folder where [fastcopy.exe] can write ( permissions allowed ), and by default fastcopy reads [FastCopy2.ini] file which is in the same folder and everything is normal here, but...

When I run [fastcopy.exe] from folder with denied write or change permission( in exact spot only User with elevated Admin-mode can write to it ), fastcopy behavior becomes strange. It's copy it's initial INI-file placed nearby to EXE to [%AppData%\fastcopy] folder and going to work with INI-file from here.

So the main problem is that, if I run [fastcopy.exe] with [FastCopy2.ini] in same folder with denied write or change permission, and in same time [%AppData%\fastcopy\FastCopy2.ini" _already_ exist fastcopy starting to work with [%AppData%\fastcopy\FastCopy2.ini" and ignores [FastCopy2.ini] in it's folder.

This behavior completely confuses me, as whole INI-file becomes unreliable since fastcopy can decide to use [FastCopy2.ini] in [%AppData%\fastcopy] folder.

And the question is...

Is it possible to make FastCopy to work with INI-file in it's folder regardless exist [%AppData%\fastcopy\FastCopy2.ini" or not?

Maybe some command-line switch like "/ini_file_location=C:\path\to\FastCopy2.ini"

Or maybe just something like "/ini_file_readonly=true"

I think Both paramters can be very useful if it's no exist now.

[Hiroaki SHIROUZU]

Thank you for your report.

I try to reproduce it, but I can't reproduce it, yet.

In Program Files or Program Files (86), FastCopy(v3) uses fastcopy2.ini in %AppData%\fastcopy\fastcopy2.ini

In another directory, FastCopy uses fastcopy2.ini in the same directory.

Even if fastcopy can't save to fastcopy2.ini in those directories, fastcopy doesn't save it to another directories.

P.S 32bit Windows(Vista or later) redirect a files to virtual store directory, if an application save a file to program files.

 But FastCopy v3 doesn't save to Program Files, it is unrelated, I think.

 ref) https://blogs.msdn.microsoft.com/oldnewthing/20150902-00/?p=91681/

[aleek...@gmail.com]

Well, it's easy to reproduce.

Let's assume we have Windows Vista of later with UAC turned on.

For example let's place our FastCopy.exe and FastCopy2.ini in C:\Windows\FastCopy directory. It's just for example, directory path doesn't matters, only write access matters.

So we have C:\Windows\FastCopy directory with both files in it and now we are sure that no user, even administrator cannot write to it without rights elevetion through UAC confirmation.

And let's check our %AppData% folder to be sure that FastCopy folder does _not_ exist in it.

And now let's lauch our exe _without_ rights elevations, just as simple user. After one launch let's check our %AppData% folder again, and now we have brand new FastCopy directory in it after launch, and 2 files it that directory: "FastCopy2.ini" and "to_ExeDir.lnk"

And every launch of exe after 1st launch wil read and save settings to that %AppData%\FastCopy.ini

So the main problem is that that i bring fastcopy's exe and in with my script, and I cannot be sure that no %AppData%\FastCopy.ini already exist on target computer. 

The main problem: if %AppData%\FastCopy.ini already exist no matter how it was created and I launch my exe from folder where user account doesn't have access to write, my exe will and work with ini in %AppData%, and even if it doesn't exist it will create it

[Hiroaki SHIROUZU]

About reproduce:

"Windows", "Proram Files", "ProgramData" are special directories.

If a normal application(32bit) write a file to these directories without write permission, the file will be redirect to VirtualStore (\Users\%user%\AppData\Local\VirtualStore\[Windows]or[ProgramData]\FastCopy\) by Windows.

FastCopy don't care about "Windows" or "ProgramData", so ini will be redirected to VirtualStore.

But, in special case, if FastCopy is installed in "Program Files", fastcopy uses AppData\Roaming\FastCopy directory. (It will be not redirected)

So, I don't recommend to use "Windows" or "ProgramData" directories.

I recommend to use fastcopy in a normal directory with write permission or "Proram Files".

If you want to learn about VirtualStore, search in https://msdn.microsoft.com or etc.

[aleek...@gmail.com]

Yes, you partially right... The original exe of was placed under "ProgramData" folder. I've tested a bit more, and when I launch exe from C:\FastCopy folder without write access to it and AppData\Roaming\FastCopy directory was not created.

Therefore I just want to mention 2 things

FastCopy if launched from folder under "ProgramData" where only elevated accounts can write:

1. Copies it's nearby Ini-file in AppData\Roaming\FastCopy ( not in VirtualStore ). It doesn't seems that Windows do that copy operation, but FastCopy itself.

2. If AppData\Roaming\FastCopy\FastCopy2.ini already exist fastcopy use this file instead of nearby ini

Can we do something about that?

[Hiroaki SHIROUZU]

Sorry, my reply...

>FastCopy don't care about "Windows" or "ProgramData", so ini will be redirected to VirtualStore.

>But, in special case, if FastCopy is installed in "Program Files", fastcopy uses AppData\Roaming\FastCopy directory. (It will be not redirected)

is not correct.

If FastCopy is installed in one of "Program Files" "ProgramData" "Windows" directories, FastCopy uses fastcopy2.ini in AppData\Roaming\FastCopy.

[aleek...@gmail.com]

Thanks, no it's clear to me