When writing to log file requires administrator privilege

[dfhtextpipe]

When writing to the TextPipe log file requires administrator privilege, there is no error message to say that it can't.

Likewise, when clicking {Delete} button in filter options.

May I suggest that filter options be enhanced with a tick box to allow run as administrator?

Background
You might wonder why on earth this would be even sensible.
When I purchased my Windows 7 (64-bit) PC, I migrated all my filters and ancillary files from my earlier Windows XP machine.
And as many of the filters called replace list files, it would have been a huge chore to relocate everything and edit all the calls.
Many of these were originally stored under C:\Program Files\TextPipe
In XP this was not a problem.
With the enhanced protection in Windows 7, the same location requires administrator privilege for writing to files.

David

[DataMystic Support]

Hi David,

I presume you are running TP as administrator already - so why do you need a check box?

If writing to the log file fails, TP places an error event in the System logs.

I'll look into error checking on the delete button.

[dfhtextpipe]

Yes - my user account in Windows 7 is already administrator type.
However, I don't normally run TextPipe with administrator privilege. The Windows shortcut properties for this is unticked.

The issue is that Windows 7 has additional secure policy settings that prevent ordinary applications writing to the program files directories.
Only installation setup programs can normally write there, and then only because you've given them permission when you open the setup.exe.

So unless I migrate all my old TextPipe filters away from where they were stored (in my Win XP days) and copied to the same location (now in Win7),
TP (like any other application) cannot write to files in these program files directories.

So for example, if and when I find I need to edit one of these old TP filters, I can't even save the filter to where it was stored. I have to temporarily save it somewhere else such as the desktop, then manually copy it back to where it was before, with deliberate forcing of the permissions during one of the Windows dialogs that pops up during file copy.

It's really a Windows issue, but the fact that TP doesn't notice that the log file is not being written to is surely in your court.
Likewise that an existing log file cannot be deleted by TP, this should be detected somehow and reported.

All my more recent filters are stored elsewhere, so the issue simply does not arise with these.
It's just those old well-established ones where I have the problem. Many of these are also programmed in the Windows shell extension.
Eventually, I suppose I'll have to bite the bullet, and migrate them to somewhere in my own user account.
Until now, I've been resisting doing so - the aphorism that applies being, "If it ain't broke, don't try to fix it".

David

[DataMystic Support]

Hi David,

A while ago I believe you asked for relative paths to be relative to the filter location rather than the current folder. Can you use this to work around this issue?

If not, could you use the Export to VBScript, search/replace, and then Import from VBScript to fix the filters?

[dfhtextpipe]

Possibly - but it's a chore I keep putting off.

I could even change the TextPipe shortcut properties so that it always runs as Administrator, but I'd rather not.
I don't want to use a sledgehammer to crack a nut.

Let's see how I fare once you've done something about TextPipe not even noticing that no log file writes were happening.

David

[DataMystic Support]

As of TP 9.1, we now throw an exception if the log file cannot be written - this halts the process completely.