Microsoft "Software restriction policies"

[Malus]

The windows version of exiftool extracts to a folder named "par-****" in current user  %temp% folder and executes exiftool.exe from this folder.

This always worked pretty well for me. Thanx once again Phil!!

But now I'm on a computer with Microsofts "Software restriction policies" that does not allow to execute programs from folders that are writeable by users.

Is it possible to move the folder "par-****" to %Programmfiles% and point exiftool to this location?


Thanx for reading, malus

[Phil Harvey]

The ExifTool executable is a PAR package.  You should be able to specify the TEMP directory to be used by PAR when running.  See the NOTES here for details.

- Phil

[Malus]

Thanx for your attention, Phil!

With admin rights I copied "%temp%/par-****" to "C:\Program Files (x86)\Tools\par". Then as user in a cmd box I set a var and ran exiftool:

>set PAR_GLOBAL_TEMP="C:\Program Files (x86)\Tools\par"
>exiftool
exiftool: creation of private cache subdirectory "C:\Program Files (x86)\Tools\par" failed (errno= 22)

It seems exitool still needs write access to this folder.


Have a noice day, malus

[Phil Harvey]

In theory, it should only need to write that directory the first time it is run.

- Phil

[Milster]

Hi Phil and  Malus (hope you don't mind me jumping in here)

Wonderful tool Phil!!!!

I am having the same problem setting a new library location rather than the user temp. Maybe Malus didn't report the error accurately the way it appears on a windows machine.
I start by setting the new global location in a command prompt...

Code Select Expand

set PAR_GLOBAL_TEMP = "C:\Temp\par"
Then I try to run ExifTool for the first time...

Code Select Expand

exiftool -XMP:UsageTerms="AUS" C:\Temp\Test.jpg
The response is...

Code Select Expand

exiftool: creation of "C:\Temp\par\"/perl58.dll failed - aborting with 22.

I think the problem has something to do with the forward slash before filename perl58.dll. Like a mismatch between the build process using a unix path on a windows computer. I tried looking at the cpan.org support pages but can't make sense of it.

Any ideas what Malus and I are doing wrong?
Thanks
Milster

[StarGeek]

I start by setting the new global location in a command prompt...

Code Select Expand

set PAR_GLOBAL_TEMP = "C:\Temp\par"

There are a couple of problems with this command as written.  Honestly, I'm surprised that exiftool was able to find the variable.

First, you're not setting the ENV variable "PAR_GLOBAL_TEMP", you're setting "PAR_GLOBAL_TEMP ".  Notice the trailing space.  Then there's a similar problem following the equal sign.  The ENV variable is being set to | "C:\Temp\par"| (pipe characters added for clarity).  That includes the leading space and the quotes, neither of which are desirable.

Both commands are incorrect because they direct the temporary PAR directory to be placed on a drive with a leading space/leading quote, which would be an illegal (?I think?) path name under Windows.

The command should be
set "PAR_GLOBAL_TEMP=C:\Temp\par"

Similarly, the earlier command should have been
set "PAR_GLOBAL_TEMP=C:\Program Files (x86)\Tools\par"

[Milster]

 
Bless you StarGeek! That fixed everything. I am so grateful for your help.
Have a great weekend!
Thanks very much!
Milster

[Milster]

One problem follows another. My use of Exiftool is in a sub within a VBS script that does a whole bunch of image processing.

Having learnt how to set the temp area I am now trying to execute that instruction but failing. Does anyone know why below fails at the MsgBox?

Code Select Expand

Dim objCMD
Dim cmdTMPline
Dim cmdPathline
Dim q

q = (chr(34))
cmdPathline = "C:\Temp\par"
cmdPathline = q & "PAR_GLOBAL_TEMP=" & cmdPathline & q
cmdTMPline =  "set" & " " & cmdPathline
Set objCMD = CreateObject("WScript.Shell")
MsgBox + "I can get this far"
objCMD.Run (CMD cmdTMPline)
Set objCMD = Nothing

[StarGeek]

I have not clue myself as I don't use vbs, but a quick google indicates that there are some ways to directly set an ENV variable without mucking about with CMD. 

Something like this (copy/pasted/mutilated code)

Code Select Expand

Set wshShell = CreateObject( "WScript.Shell" )
Set wshSystemEnv = wshShell.Environment( "PROCESS" )
wshSystemEnv( "PAR_GLOBAL_TEMP" ) = "C:\Temp\par"

From what I read, wshShell.Environment( "PROCESS" ) sets it for only the current processes.  SYSTEM or USER sets the ENV permanently

[Milster]

StarGeek, after 12hrs of mutilating my code attempts you come to the rescue.
That worked a charm.
I am very very grateful for your help!
THANK YOU
*applause*

[bmn]

Hi,

I'm trying to get ExifTool running on Windows with the following criteria
- all users of the computer shall use the same installation (not a copy in every user's profile folder)
- normal users shall not be able to tamper with the files (read only for normal users)

I found this post and thought it fits perfectly, so I
- created the folder C:\Program Files (x86)\PAR
- set the variable par_global_temp to C:\Program Files (x86)\PAR
- ran ExifTool for the first time as an administrator, so that the "installation files" are created

I'm not sure if you can influence the behavior, as it's a mechanism of PAR...
But
- while the default dir with par_global_temp unset is $temp\par-$user\cache-$program-$version, the installation directory with par_global_temp set is directly $par_global_temp, so using another tool, which is packaged with PAR will probably cause a file conflict (at the moment, we are using only ExifTool)
- running ExifTool without command line args fails, because ExifTool tries to create "c:/program files (x86)//exiftool_doc.txt", which must obviously fail

I'm testing with ExifTool 11.26. You wrote, that write access is only needed for the first time and only for par_global_temp, not for a directory one level up. Has this changed? It seems ExifTool creates this file temporary and deletes it afterwards, so that it's not possible to run it as normal user without write access.

Could you
- use a directory within $par_global_temp and create exiftool_doc.txt once as all the other files or use user's $temp dir for temporary data files you create on the fly?
- change a setting, that a program (and version specific) subdir is used, even if the variable par_global_temp is set?

Thank you

[Phil Harvey]

I'll look into putting the .txt file in the temporary directory.  Thanks for this report.

- Phil

[bmn]

Thank you very much. This will help me a lot.

[Phil Harvey]

I finally got a chance to look into this.

Current ExifTool writes the temporary file to one level higher than PAR_TEMP by default.  You should be able to set PAR_TEMP to change this.  If PAR_TEMP is not defined, then the file is created in TMP or TEMP, whichever environment variable is defined.  I could maybe change this to use PAR_GLOBAL_TEMP if it is defined.  The way it would be is that the .txt file would go to C:\Temp if PAR_GLOBAL_TEMP was set to C:\Temp\par.  Would this be OK?

- Phil

[bmn]

I used PAR_GLOBAL_TEMP, as recommended in this thread. PAR_TEMP is not defined on my system.
Actually the behavior to use TMP or TEMP for the text file would be fine.

My goal is:
- Standard users should not be able to execute programs in user writable folders. So for example can't execute files which they downloaded or were downloaded in their user context from the internet
- So creating data files in TEMP (a user writable folder) is fine, while creating a program file and executing it from TEMP will fail. (Basically, it's the same as extracting a downloaded zip file to TEMP and executing...)

By default, TEMP and all it's subfolders are user writable on Windows, while all subfolders of C:\Program Files\ are not.
Making a subfolder of C:\Program Files\ user writable isn't a nice solution. It's almost the same as the actual situation, where I have to deny write access for a user to a subfolder of TEMP.
From the point of security and privacy, the actual situation is probably even better as each user has his own TEMP folder, while the user writable folder in C:\Program Files\ would be shared for all users (or I'd need also one instance for each user in different folder structures).

My problem would be solved
- If all files would be created the first time the program launches and afterwards only read access will be required
- or if i can completely (independently) separate the installation (program files) from the working (where files are created at runtime) folder

Having the fixed dependency to a directory one level up is a problem in my scenario. But I guess my thoughts are also valid for any multi user Linux system.