After installation the exe has a padlock on it

[NewsArchive]

Just one of my users experiences a problem after every update. For some
reason the exe gets a padlock on it and he has to call his tech to fix. The
tech claims we are not applying the shared attributes to the file. How can
this be? The pc in question is Win 8.1 64 bit.
Thanks
Nev

[NewsArchive]

Forgot to mention the installer is set to apply the same file attributes as
the file it replaces.

Neville Wright

[NewsArchive]

Hi Neville

>Forgot to mention the installer is set to apply the same file attributes as
>the file it replaces.

Maybe you don't need the installer/Updater to do that. I never do.

Also, what is the name of the EXE that you have SetupBuilder create?

Does it have the word "setup" or "Install" or "update" in the file name? These are
needed to ensure updater is run with admin rights.

JohnG

[NewsArchive]

Hi John. The word upgrade is included in the compiled exec name. So you
suggest I change the name?
Nev

[NewsArchive]

> Forgot to mention the installer is set to apply the same file attributes
> as the file it replaces.

It has absolutely nothing to do with the file attributes!

IMO, it's a typical permissions/sharing thing (if you see the lock icon).
This might happen when you replace in-use files and Windows has to reboot to
complete the installation (replace locked files on reboot). The Windows
CopyFile API does not copy security attributes. And btw, this is not only
on Windows 8.1 but on all Windows versions!

What you can try to do is:

1. Do not overwrite locked files (check if the files are in-use BEFORE you
process the install file operations).

2. Set the temporary file folder to your installation folder (see "Set
Temporary File Folder..." script function).

Hope this helps a bit.

Friedrich

[NewsArchive]

BTW, and this:

http://www.lindersoft.com/forums/showthread.php?p=75363#post75363

http://serverfault.com/questions/537544/what-is-the-best-way-to-fix-ntfs-file-permissions-to-inherit-parent

Friedrich

[NewsArchive]

How about right-clicking each parent directory, going to Properties, then
Security tab, then click Advanced, then click Change Permissions, then check
that checkbox that says "Replace all child object permissions with
inheritable permissions from this object"? – Ryan Ries Sep 9 '13 at 17:21

The above is exactly what we tell them every time but I would still like to
work out why it happens at this one site.
Nev

[NewsArchive]

Thanks Friedrich
Before installation we check to see if the exe is running and if it is, then
apply 'gently close'. However I am not sure if that applies to multiply
copies of the exe running over a network. No reboot message appeared as I
asked the user. So I assumed that no copies of the exe were still running.
BTW this is the only site where this happens. No other users have
experienced the problem. I know it is permissions but cannot find what
causes the exe to locked on replacement.
Nev

[NewsArchive]

Hi Nev

>I know it is permissions but cannot find what
>causes the exe to locked on replacement.

So does this problem user site run a different antivirus to the others who do not see
the problem? That seems likely.

John

[NewsArchive]

Nev,

> Before installation we check to see if the exe is running and if it is,
> then apply 'gently close'.

As I understand it, you are running the install/update on the server, right?
But your own application is NOT really running on that server. The clients
just connect to the server and "start" the executable over the network.
That means your exe is running locally on the clients, not on the server.
But of course, this action "locks" the .exe and dependency files (.dll) on
the server! To replace the files, Windows has to reboot the machine.

BTW, the use of "Detect Active Application" function only makes sense if the
executable is running on the destination machine (the server in your case).
If the exe is "running" over a network (on different clients) then you can't
use this function! And gently close does also not work in this scenario.

You can use the "Check In-use File..." or "Check In-use Folder Tree..."
functions to detect "locked" files.

Friedrich

[NewsArchive]

> The above is exactly what we tell them every time but I would still
> like to work out why it happens at this one site.

Because a Windows reboot was required to complete the installation process
to replace locked (in-use) files.

Friedrich

[NewsArchive]

Trend Micro, the same as me.

Neville Wright

[NewsArchive]

Thanks Friedrich

Neville Wright

[NewsArchive]

I've been in this situation a number of times.

What I've often done is to have the program check for the presence of a text
file every couple of minutes. (Timer on the frame.)

If it finds a file (usually in the program's installation folder) called
something like SHUTDOWN.DAT, then it starts giving warning messages to the
users.

After 10 minutes or so, it halts the program.

When the program is started, it also checks for the existence of that file.
If it finds it, it halts with a message to the user. (Unless the program
has been started with a particular command-line switch which lets an
administrator test it while the SHUTDOWN.DAT file is present.)

Otherwise, as Friedrich says, various remote users will have files locked in
the server folder.

You can also go into compmgmt.msc on the server and kill the individual
connections, but that's a wee bit less graceful...

jf

[NewsArchive]

Thanks Jane
All comments appreciated.
Nev

[NewsArchive]

Thanks Jane
Actually I do that with another app to see if it is running. Thanks for the
heads up.
Nev

[NewsArchive]

>You can also go into compmgmt.msc on the server and kill the individual
>connections, but that's a wee bit less graceful...

Nettalk has an easy to implement NetAuto-Function, which lets you detect all
machines, which are accessing your program. Even more, you can send a message
to all clients, to close the program due to maintainance. If they have not
obeyed within X minutes, because they had left their desk and do not see your
notice, you can close all EXE remotely.

I have added this functionality into a separate Admin.EXE, its works fine - as
long as the proxy-settings do not prohibit you to see the running
instances.


Regards,
Wolfgang Orth
www.odata.de

[NewsArchive]

Thanks Wolfgang. I'll look into that idea further as I use that same
function when I remote into a site.

Neville Wright