OperaDriver fails to use launcher to run opera on Windows

[lkende]

Something changes between selenium 2.11.0 and 2.13.0. I was able to run tests on Opera 11.5 on Windows 7 no problem, then with upgrade to 2.13.0, suddenly getting this message:

"Unable to extract bundled launcher: Unable to set modification time for file: C:\Users\you.launcher\launcher-win32-i86pc.exe "

Not sure that 2.11 uses the bundled launcher. It's as if there's some sort of permission or timing issue here because when scripted, I get the message above, but when manually run my test on command line, it appears to work ok.

If I'm right in that 2.11 did not use a launcher binary, then is there a setting to not use this launcher until I get permission settings checked out? Or is there something else I should be aware of with the launcher?

[andreastt]

I'm suspecting this happens because we don't close the FileOutputStream before modifying the file… OperaDriver 0.8 added a check for whether setLastModified() succeeded. One solution would be to disable this check.

But does this happen consistently on your system?

(Also to use Opera 11.52 or older you need to set opera.port to -1 and opera.profile to "" (empty string) for it to work out-of-the-box. Or you can upgrade to 11.60 or newer.)

[lkende]

Yes it is consistent in as far as running the java command from a python script that runs as administrator (that's what I meant by scripted), but when I go in and run the java test on the command line it does not give me this issue, hence I believe it's a permission issue (since running on command line runs as the user).

I am using the port and profile as indicated since it's 11.52, I had to do that so it would work on other configs (Mac, Linux).

How do you disabled this "setLastModified() succeeded" check? I 'm trying to use distribution selenium-standalone versions and not have to modify the jar or include separate files in the classpath. Sounds like this change may require that so I am staying on sel 2.11 for now, but have to conditionally use 2.13 for Opera to run on Ubuntu 11.10 due to shared library dependencies.

We use selenium across lots of browser versions (I work for crossbrowsertesting), so upgrading does not really fix things for me. In fact I am still using OperaDriver for versions 10.5 and above (flaky but works most of the time).

It sounds like the real answer is that I need to go in and see what's going on now that there's a launcher binary... that was my question: when did the launcher binary get added? Can it be turned off? (especially since it doesn't work with 10.x versions)

[andreastt]

Can you try out https://github.com/operasoftware/operadriver/tree/andreastt/last_modified_no_check and see if that works? Simply check out the branch and do ant jar to compile a new OperaDriver JAR. Does this fix the problem for you?

If we can verify that this fixes your issue, we can push that to the next Selenium standalone JAR.

The launcher binary was added a long time ago and shouldn't be dependent on any specific Opera version as it does not communicate directly with Opera. The launcher executes Opera as a child process so that we have better binary control than what Java gives us by default. It also solves some issues with taking screenshots.

[rjatkins]

I've also seen this issue. It looks like Windows (not just 7) implements setLastModified using an exclusive file lock, which conflicts with the write lock the open FileOutputStream has (see http://stackoverflow.com/questions/1144635/setting-the-last-modified-time-of-a-directory-opened-for-readdirectorychangesw). The solution would be to move the modification date change below the try/finally block.

The reason this isn't always failing for me is that the next time we get into this code path, the launcher already exists in my home dir and its MD5 sum is identical, so the write and setLastModified aren't attempted again. It will break again the next time that md5 check fails though.

Strangely, the code isn't checking the last modified date at all - it only does a MD5 on the content. Maybe you can just remove this code altogether?

Also: it looks like the if != null checks in the finally block can be simplified: Closeables does the right thing with nulls.

[andreastt]

I believe this has been solved in HEAD now.

[rjatkins]

This is not fixed on master: the unnecessary call to setModifiedDate is still there, and it still causes the first attempt to install the launcher on a clean machine to fail on Windows 7 (and almost certainly all other windows systems, for the reason I linked above). To reproduce, be sure to clear out your C:\Users\foo.launcher directory before attempting to create a new OperaDriver instance.

[andreastt]

Terribly sorry about that, was sure I had merged the patch. I've now removed the check for whether setLastModified() fails. Does this work for you? I'm not able to reproduce this issue on Windows XP when running ant test…

[rjatkins]

I can verify that this fix works. Still, I'm not sure why you even need to call

targetLauncher.setLastModified(targetLauncher.lastModified());

since the act of writing to the file will bump the last modified date on all OSes I've ever heard of, and this code will simply set it again to its current value - in short, it's an expensive no-op.

[andreastt]

I agree. I asked stuartk (old maintainer) what it was and he said it was from the days when we did date-modified comparison (rather than byte/hash comparison as we are now), so this can safely be removed.