Test to see if "file in use"

[stevengraff]

My script's installation script bombs out when using ExtractAttachedFile if there's an existing file currently in use. Is there a test I can run prior to ExtractAttachedFile that would allow me to tell the user that file "xyzzy.dll is in use, stop existiing related processes, and try again?"

I thought maybe if fileExist("xyzzy.dll") == 2, but that seems to be only for files that can't be read. Apparently fileExist(filename) == 3 is not an option in my version.

Thanks,
Steven

[td]

After checking for existence, attempt to open the file for unshared writing.  Trap any resulting error.

[td]

As an alternative to throwing up an error when you can't extract a file, you could try to rename the existing unaccessible file instead.  Often, files locked because a process holds a module handle can still be renamed.  Once the file is renamed successfully, you could use IntControl 30 to mark the renamed file for deletion on the next reboot and extract your new file.

If the file cannot be renamed or marked for deletion, you could still fall back to an error.

[stevengraff]

intcontrol 30 looks like a queer duck. Obviously the script is not auto-restarting upon fresh boot, so... does Windows maintain such a list of files to move internally? WinBatch just tells Windows, "here ya go, move these files next time 'round?"

[Deana]

intcontrol 30 looks like a queer duck. Obviously the script is not auto-restarting upon fresh boot, so... does Windows maintain such a list of files to move internally? WinBatch just tells Windows, "here ya go, move these files next time 'round?"

As I understand it, IntControl30 merely sets some registry keys that the system uses to complete the operations at restart in the same order that they were issued.

[td]

intcontrol 30 looks like a queer duck. Obviously the script is not auto-restarting upon fresh boot, so... does Windows maintain such a list of files to move internally? WinBatch just tells Windows, "here ya go, move these files next time 'round?"

Nothing 'queer' or 'ducky' about it.  IntControl 30 simply gives you access to a service provided by the OS.  The one caveat is that the IntControl  does require that the caller be a member of the administrative group or be the LocalSystem account.

[td]

Neglected to add that while MSFT documentation  for the underlying API doesn't state so, the IntControl 30 caller needs to be an elevated admin on Vista/2008 and newer with UAC enabled.  This can be inferred from the registry location used to record the names of files to be moved or deleted. I imagine this inconvenience could be described as just 'ducky'...