Installing new wodUpdSv.exe with Installshield (General questions)

I feel I'm the only one reporting problems on the forum, since the last 2 topics were all from me, and here I go again.
I might have encountered a bug with wodAppUpdate. When using Installshield, I added the wodUpdSv.exe inside the project, put it in the [System] folder, and registered it as a service (all inside Installshield). The service also appears to be running. When I try to update some files (without an Administrator access), the files are downloaded, but aren't updated. The CMDAFTER command is executed afterward. Each time I check for updates, the same files are downloaded, but they are still not updated, and CMDAFTER is executed. If I do the same thing, but with admin privilege, everything works great.

Did I miss a setting in Installshield? Must I specify the name of the NT Services in a specific way?

Alexandre,

Can you please check what does ServiceIsRunning property return when Update is ran?

Also, what account is Service running on?

Does it work if you install it using our installer?

Regards,
Damba

I do not know what the property ServiceIsRunning return, because there is no development environment on the test machine, and the test machine is in japanese.
EDIT : ServiceIsRunning returns true.

The service was installed with the administrator account. The one attempting to update is a standard user (user with power). The service seems to be running under Adminstrator user, but since it is in Japanese, I might be mistaken, but they use the same ideograms as the Administrator account.

After installing with your package, it works perfectly, both user with powers, and restricted user.
EDIT2 : Apparently, it did not work. The package I installed already had the udpated files (my mistake). So, installing your package does not work on the japanese test machine.

I suspect the service name has something to do with it. I will modifiy the code to display a message box with the value of the property ServiceIsRunning .

Alexandre,

Also, please check what account does the service run under. You can check that in Administrative Tools -> Services -> AppUpdate service -> Properteis -> Log On Tab.

Regards,
Damba

I found something really interesting. If I take my application, put it on the desktop, and run it, everything is updated. If I put the file on a common folder (ie : C:Updater), it updates and replaces files. I think it might to do with authorisation over the installed folder/files with Installshield.

Alexandre,

Can you please check what I suggested in my last reply?

Also, what OS does this happen on? Does this happen only on Japanese version? Can you try on English?

Regards,
Damba

I do not have a log on tab, but the closest one is Connections which states Local system account (translated from french to english).

It happens with windows XP SP3 Japanese and Windows Vista. Windows XP SP2 Korean seemed to work just fine.

I investigated further with the authorization problem I was talking about in my earlier post. If I have a clean vista computer, install my application with a InstallShield 2009 Professionnal installer I created (which simply starts the wodUpdSv services, register the wodAppUpdate.dll, and copy my application), and try to update, nothing is ever updated. But, if I take the same application I created (that was installed with InstallShield), create a new folder in the C: root folder, put it there, everyone (admin, power and restricted users) can update it.

I also noticed that the owner of the created install directory is the user SYSTEM , which I assume has greater access than administrator. I gave myself ownership over the files and folder of that directory, but it wouldn't update.

UPDATE :
After messing around some more, I found that if I give the Users full control over the directory, every user is able to update the files. All of this is assumption, but I suspect the problem arise because the service does not have proper access to the directory (because of InstallShield), or the service is trying to replace files without itself being of proper level access (which I doubt, since updating NOT in a folder created by Installshield works perfectly with both power and restricted user).

I will post a step by step guide if I ever get this solution to work.

Alexandre,

Can you try giving it admin rights, by changing to user and entering credentials (just for test)? Does that work?

Also, where do you execute the update from? What path?

How can I duplicate the same issue? Can you please provide me with instructions? Can I use our sample for that purpose?

Regards,
Damba

Giving Administrators every right does not seem to change it. Giving Users every right corrects it.

The execution path is C:ProgrammesMyUpdater which is the default Program files directory on a french vista installation.

To duplicate it, you have to use InstallShield. Create a new project, add an updater application (your sample should do it), add the wodAppUpdate.dll(set the property to Self Register and the wodUpdSv.exe. In the Organization section, subsection Components, expand the wodUpdSv.exe component, expand Advanced Settings , and in the Install NT Services section, add a new NT Services entry. Create the installer (F7), and install the package on a Windows Vista machine. If you execute your application, it won't be able to update your files. It will download them, but won't update them. But, if you give the rights to Users on the directory, everyone will be able to update.

If you install the software on another Vista machine, but instead of giving permissions to Users , you copy the updater application (your sample in this case) in any other directory accessible to every user (say, a USB drive, or the C: directory), and execute it, it should update properly.

EDIT : Something that just popped up as strange too is that permissions inheritance is not always applied. Folders seems to inherits proper permissions, but not files. Might it have something to do with all of this?

UPDATE : I just remembered the post about Permission Revisited . Might it be a recurring bug? It seems to be closely related, because I have the same file permission problem as the original poster.

Alexandreo,

When you want to use Vista as non admin user. It's not wise to user application inside Program Files folder.

On Vista because of UAC and virtualization of Program Files folder. Program Files folder is different for admin for all non admin users.

For example, if an application attempts to write to C:\program files\appname\somefile.txt and the user doesn't have permissions to write to that folder, the write will get redirected to C:\Usersusername\AppData\Local\VirtualStore\Program Files\appname folder.

Maybe changing folder Program Files folder is best idea.

If this is not accepted. I can only suggest workaround that maybe wiil work. I found it here:
http://community.installshield.com/showthread.php?t=180642

Drazen

EDIT : Clarification was needed.

The solution provided does work, but I encountered another problem, which I thought was the same Installshield problem, but now I'm pretty sure it is related to wodAppUpdate.
Here is a way to reproduce my problem :

Admin install my Updater for user1 and user2 (both users have restricted access). If user1 updates the application, user2 won't have access to the updated file, because wodAppUpdate ignored inherited authorization. Strangely though, folders do have proper authorization. So, when user2 run the application, it asks to download the same updates, updates the files, and now it's user1 that will have authorization problem, and the cycle goes on.

Here is the file authorization

Here is the folder authorization

Alexandre,

Can you please try this outside Program Files folder. What happened?

I already mention in my last reply issue with Program Files folder about what happened when restricted user try to write to Program Files folder.

Drazen

That problem has been solved. Both user can update files in the program files. Both user can also update files in another folder than Program Files. My problem now is the updated files does not have the proper permission to allow user1 and user2 to coexist. If user1 updates the files, user2 no longer have access to them, but can still update. If user2 update, he must download every single updated file again, and this time, user1 does not have access. If user1 runs the updater again, he must redownload the same files again, and user2 will no longer have access anymore.

That problem is exactly the same as the one described in the forum post Permission revisited . The problem is that the updated file do not have the proper permission. If you look at my previous post, the screenshot I took it indicates that the folder have been created properly, but not the files. The files are accessible only to the specific user who updated it, and not to anybody else, and that is the root of my problem.

Alexandre,

Can you please just try to update outside Program Files folder?

I want to be sure how it work there. Please create some folder on C:\ and try it again with both users.

Thanks,
Drazen

Already done, and with the same result described earlier on both Windows XP and Vista.

EDIT : The problem is no longer with the Program Files folder permission. That was solved (as mentionned in an earlier post). The problem really is when restricted user1 uses the application to update files, and restricted user2 uses that application afterward. user2 won't be able to see files updated by user1. As a result, user2 will have to update, thus replacing files that were updated by user1, but not accessible to user2.

Hi Alexandre,

I assume this is an issue with ownership, since the user that downloaded the files is set as an owner, while other users won't be able to access them.

Can you delete/access those files with user2 after user1 did the update?

Regards,
Damba

I can see the files with user2, but I cannot delete nor copy.

Alexandreo,

I was able to duplicate your problem on Vista, and I'm not sure if this is a bug or a feature. When 'user1' creates the file, it inherits directory permissions which usually means owner has all the rights, others don't have even read rights. When other user wants to access them, you get more less error you noticed - access denied.

Now, how to workaround this isn't nice.. I can set ACL to 'Everyone have all access' but I'm not that happy to do it. What would you suggest to fix your problem, but at the same time does not reflect to make insecure updates which anyone else could interfere with?

I think perhaps adding new property for each file where you could set it to 'Everyone can read/write' by yourself. Would that help?

Kreso

My ideal solution for my current project would be to make the files properties the same as the folders. But I understand that it might be troublesome for other people's projects. I think your suggestion about adding a everyone read/write flag to the config.txt could be nice.
Otherwise, it might be a property on the wodAppUpdate object itself to determine which access to grant. A list of standard groups like Administrators and Users might be useful for future project. I think I prefer to add the flag inside the config.txt since it allows for a per-file permission. The only downside I see to this is that our current config.txt file is rather big at the moment, and I expect it to only grow. It weighs 252 Ko, and has about 910 entry, is downloaded each time the application is started, and we expect a rather large user base. So, adding a single line in each entry means adding 910 lines. But I suppose my project is more of the exception than the norm.

On a side note, a really nice feature would be to be able to read a config.txt file that has been zip/tar.gz/rar. That would benefit greatly our project.

Alex,

let's start with adding the property for each file in the wodAppUpdate activex. How would you name this property, and what type would it be to make it easy to use? I was thinking something like

File.Permissions( Everyone ) = PermRead+PermWrite+PermExecute
File.Permissions( Owner ) = ....
File.Permissions( Administrators ) = ...

is that something you had in mind?

I'll see about supporting compressed config file. Do you have sensitive data inside? Do you need to encrypt it as well?

Kreso

Alex,

I have updated wodAppUpdate to support compressed config files. Now you can do

UpdSqueze your_original_config compressed_config

and ignore all the screen output of the updsqueze program, and upload 'compressed_config' on the server.

Can you try it out and let me know if it's ok?

Kreso

That was exactly what I had in mind! The only concern I have is with internationalization, but since the updater works perfectly (except for the file permission problem) on a japanese Windows XP machine, I think you guys have already figured it out.

As for encryption, I do not need to encrypt my data, but I think it might be a nice feature. Although I'm being overly sensitive about what I have posted about my project so far, it is simply an unreleased project. The reduction in size of config.txt is more important to me right now to unload the file server.

EDIT : Wow! That was really fast! I'll get right on that before the end of the day (it's now 13:23 EST GMT -5).

EDIT2 : Just to be sure, I also need the possibility to set the file permission to be inherited from the parent directory. In fact, folder security is perfect the way it is, I simply need it to be the same for files updated. Could there be an estimate of when it might be possible? I need to deliver a software with this feature by Wednesday midnight (GMT -5).

Alex,

ok, request update again (or download DEMO if you're still evaluating) and try it now. You will be able to do this in DownloadDone event:

wodAppUpdate1.Files(0).Permissions( Everyone ) = PermRead + PermWrite + PermExecute

please note that this will be effective only if this is new file on the system - if you are only replacing or updating files, it will keep it's permission settings. But I believe this will solve your problems.

Besides 'Everyone' you can use any group name, user name, or well known SID (best way to do it!), refer here: http://msdn.microsoft.com/en-us/library/aa379649(VS.85).aspx

Regards,
Kreso

I did not receive an estimate about the other feature that I requested, about inherited permissions. Might I ask if it will be possible to have that feature?

Alex,

I somehow missed your request since it was added after I've read the forum post, and I was expecting your reply to my latest change.

I have to see if we can add this possibility, since right now it depends on what OS gives us. When files are dropped to temporary folder, they receive default permissions for that folder. In all cases it's based on security permissions of parent folder.

HOWEVER - if there is already original file that is to be replaced, his permissions are preserved, sinec we pump up contents of new file to the old file, without replacing the file.

Are you experiencing differently?

Kreso

No, I think I experience the same thing.

What I assume happens is user1 update and then user2 try to update. Since user2 cannot see the files, the udpater asks the service to download and replace the existing file with the default permission of the temp directory(which probably is under the control of user2).

The feature that I requested in my 2nd edit was to be able to set the file permission to be the same as the folders(which I assumed was inherited). I hope I made my explanation clearer. Do not hesitate to ask if more details are needed.

What I do not understand though is that folders probably use the same method for updating as files. I assume that they get created in the temp directory, with the default permission (which would still be under the control of user2), then copied back to the proper update folder. What I do not understand is that those folders do have the proper permission that I am looking for, which I assumed was inherited from the parent directory, but seems to be otherwise with your explication. Am I missing something?

ps : I did not have time to test the compression of the config files. I will do this when the time permits it.

Actually, I think problem will remain, since original folder is created by administrator during installation.

I can change the ownership to same as who created the folder if you think that will help. However, even now, you could use new Permissions feature and set Permissions( Everyone ) = PermRead and your problem would be solved.

Kreso

I'm not sure we're talking about the same thing. Ownership of the file is not really that important right now to me. What I'm more concerned with is file permission.

Let's say there's the root folder of the updater application. User1 will use the application which needs to update File1 and File2 , which must be situated in the root/UpdatedFiles folder. The application will then create files in the temp directory of User1. Once the files have finished downloading, the application will ask the service to put the files inside the root/UpdatedFiles folder. Since that directory does not exist yet, it must be created. The application will create the directory named root/UpdatedFiles , and will cut/paste File1 and File2 inside it. If I look at either File1 or File2 directory, the permission will reflect the ones inside the temp directory of the user that updated the files(in this case, User1). If I look at the permission for the folder UpdatedFiles , everything is perfect.

I could always set the permission manually with the new updated version, but that wouldn't take into account inheritance.

By the way, a big thank you for the enormous support you have showed me. It is really appreciated, and speaks for the passion you take into your product.

I think I understand what you're saying. I use MoveFile API to move the file from the temp.

If I do it differently, and *create* the file on destination, and then paste contents from the temp, that would do the trick. Correct?

But now I have a problem - that could interfere with Permissions properties I just added since they will be ignored..

Kreso

I think that is exactly the solution I'm looking for. It would be really appreciated if it could be implemented.

I suppose it might be a problem if the file is no longer moved from the temp directory, but can you apply the change on the file created in the application folder?
Something similar to : Create the file in the application directory, download the file in the temp directory, paste the file from temp into the application file, and then apply rights on the file in the application directory?

The problem I foresee has to do with the wodUpdSv.exe service. I suppose it wasn't designed to change permission of updated files inside the application directory. I suppose it was designed to move them from the temp folder to the application folder, or give a write stream from files in the application folder to the Updater program calling it.

Alex,

updated, can you try it now? Now it will createfile, then pump to it, if you don't touch new Permissions feature.

Kreso

After testing it, it does the same thing as before. Something I just noticed though is that if I create a new folder, permissions are set perfectly. But if I create a new bitmap image, the permission is exactly the same as the updater. So, if the file is in the temp directory, then moved, or if the file is created inside the application directory, the permission remains the same.

I think that with that realisation, my problem becomes outside the scope of the intended use of the updater.

I'm trying to use the Files[1].Permissions( Administrator , PermRead + PermExecute) method, but I do not find any enum that ressembles PermRead , or Perm , etc... I also do not find it in the online documentation of WodAppUpdate, nor in the webpage about well known SIDs.

edit : Please not that I'm also using C++ (not that it should make a big difference)

We just added those. You should probably reimport the DLL into the C++

They're not in the docs yet, I was waiting for your confirmation it works ok.

Kreso

I did reimport the dll (using the class wizard, MFC Class from TypeLib). I started a new project and imported it just to be sure that I wasn't missing anything, and still, nothing ressemble PermRead or Perm (except set_permission and get_Permission).

Well, after some test with SetPermission, I think it does not work properly. I've tried to set permission (using this as a base for SetPermission argument), and it does not work. Whatever I put in the argument section, if I use well known SID like S-1-5-32-547 (Power Users), they are not added neither to the permission nor the security tab. I see exactly the same thing as before.
Might it be a slip up with the last update with files created first, then streamed to?

If you check before calling Update, in the TEMP directory, are permission applied?

Kreso

Permissions are not applied in the temp directory. But that is, assuming that the link I gave you works for this too. Here is my current line that change the permission :
[code]updFile.SetPermission(L S-1-5-32-545 , 0x10000000);[/code]

According to the previous link I wrote, it's supposed to allow everything for users . But when I look at the permission, the group Users are not mentionned.

Alex,

in the meantime new version has been published with changes related to Permissions. Now all files that are updated (no matter if they exist or not) can get new permissions. Can you try your code now?

If it doesn't work, can you send some example of what you're trying to do to techsupport so we can duplicate the problem?

Kreso