File Open problem

[slouw]

Hi There

After rebuilding a Win7 environment I have a script (working perfectly before) now broken.

I am at the point where running FileOpen01.au3 (From help folders) is failing with

$file = FileOpen("test.txt", 0)

returning -1.

So far I have

- Checked READ only attributes on folder in question

- Turned UAC down to "never"

- Ticked this checkbox - C:\Program Files (x86)\AutoIt3\AutoIt3_x64.exe > Properties > Campatibilty TAB > Privilege Level > Run this program as an administrator

- Reloaded

Any ideas? Thanks for any reply

[guinness]

What version of AutoIt are you using? And where is the file located?

[BrewManNH]

The folder where the help file examples are saved in is a protected location, meaning a normal user doesn't have write access to the folder. If you change the file location for test.txt it will probably work.

[slouw]

Thankyou for the replies.

I am researching NTFS issues centred around this topic (below)

http://support.microsoft.com/kb/326549/

It seems AutoIT may be one of "Some programs" as referred to in the KB article.

Exerps include:

Unlike the Read-only attribute for a file, the Read-only attribute for a folder is typically ignored by Windows, Windows components and accessories, and other programs.

The workaround has given me no joy. It involves

use the Attrib command at a command prompt (Cmd.exe) to view or to remove the Read-only or the System attributes of folders

These for example did not do the trick:

D:\>attrib -r +s D:\TTemp

D:\>

D:\>attrib -r -s D:\TTemp

So for the moment this has turned into a more pure Windows thing. Once I have gotten past this I will update this post hopefully to say all fixed now this is what you do

Thanks again

[BrewManNH]

The folder isn't read only because the Read-Only attribute is set, the folder is protected by the security settings for the Program Files location in Windows 7. Move the file or give the script admin rights and it should work.

[slouw]

BreManNH

I have the following folders in play:

D:\TTemp Test folder where my test script is located. When I run the script from here I have the fault. My previous post was focused on the properties of this folder.

C:\Program Files (x86)\AutoIt3 – Familiar to you I think. Since I am running Win6x64 I presumed that it was AutoIt3_x64.exe in play. This is borne out by what I see in the task manager when I run the test script. See screenshot below. It appears to be AutoIt3_x64.exe that is running the script.

I am accepting of what I think you are saying first off – this has nothing to do with the READ ONLY attributes of D:\TTemp.

I am not clear however of the second thing you say. You refer to the

Program Files location in Windows 7

Could you clarify? I am anticipating you are going to specify something about the following screenshot.

I have applied FULL CONTROL to all Groups and Usernames In the screenshot and reloaded. No joy. The screenshot below shows the security setup for the C:\Program Files (x86)\AutoIt3 folder. The same FULL CONTROL permissions are assigned for all Groups/Usernames for both

AutoIt3_x64.exe and AutoIt3.exe. Was this the security setup you were referring to? Any replies gratefully received.

[slouw]

After much troubleshooting this is fixed. I thought i would update.

The problem is for some reason post Win7 rebuild (and Directory Opus upgrade - Windows Explorer replacement. Rocks) my script was forgetting the correct current working directory.

So what I thought was permissions was not pemrissions at all.

The script creates a DirOpus specific shortcut. A small text file looks like XML with target path embedded.

If I execute the script directly (i.e. highlight the script file from DirOpus and press enter) then it works perfectly. In this case the script and the current working directory are the same.

However I am running the script from a command within my WinExplorer replacement. In this case unbeknown to me the .dcf shortcut files were piling up in the system32 directory.

Workaround is to assign current working directory explicitely with FileChangeDir.

Strange becuase the script does other keystroke things which is context dependant i.e. acting on the instance of DirOpus from where it was called.