Auto-update renaming about ripme HOT 9 CLOSED

Tested with 1.0.3, same result. Log:

2014-04-08 18:35:02,551 0 [main] INFO ripme.App - Initialized ripme v1.0.3
2014-04-08 18:35:05,890 3339 [AWT-EventQueue-0] DEBUG ui.UpdateUtils - oldVersion 1.0.3 < latestVersion1.0.12
2014-04-08 18:35:05,925 3374 [AWT-EventQueue-0] INFO ui.UpdateUtils - New version found, downloading...
2014-04-08 18:35:09,789 0 [main] INFO ripme.App - Initialized ripme v1.0.12
2014-04-08 18:35:09,790 1 [main] INFO ui.UpdateUtils - Deleting existing .jar file: ripme.jar
2014-04-08 18:35:09,790 1 [main] ERROR ui.UpdateUtils - Failed to rename file from C:\ripme.jar.update to C:\ripme.jar
2014-04-08 18:35:10,008 219 [main] DEBUG configuration.PropertiesConfiguration - FileName set to rip.properties
2014-04-08 18:35:10,009 220 [main] DEBUG configuration.ConfigurationUtils - ConfigurationUtils.locate(): base is null, name is rip.properties
2014-04-08 18:35:10,009 220 [main] DEBUG configuration.DefaultFileSystem - Could not locate file rip.properties at null: no protocol: rip.properties
2014-04-08 18:35:10,012 223 [main] DEBUG configuration.ConfigurationUtils - Loading configuration from the context classpath (rip.properties)
2014-04-08 18:35:10,012 223 [main] DEBUG configuration.PropertiesConfiguration - Base path set to jar:file:/C:/ripme.jar.update!/rip.properties
2014-04-08 18:35:10,027 238 [main] INFO utils.Utils - Loaded file:/C:/ripme.jar.update!/rip.properties
2014-04-08 18:35:11,145 1356 [AWT-EventQueue-0] INFO ui.UpdateUtils - Running latest version: 1.0.12
2014-04-08 18:35:24,640 14851 [Thread-4] INFO utils.Utils - Saved configuration to C:\rip.properties

Also not sure if intended, but rip.properties is now in the same folder as the .jar file.

from ripme.

Backed up copy of 1.0.11: http://rarchives.com/ripme-1.0.11.jar
For reproduction purposes

The error you're seeing happens when the program can't rename the .jar, likely because another process is reading the .jar. Do you have anti-virus installed?

I can add a retry-loop to wait for the file to become available (3-5second wait).

And rip.properties has been persisted in the same folder as the .jar since 0863a93

from ripme.

No I do not have antivirus stuff installed, can reproduce the bug consistenly. Performance monitor only shows "System" proccess accessing the file.

I'm using Administrator user profile and I have Full Control rights to the file. I tried opening Full Control rights to all users for the file and the folder, and the only thing that did, surprisingly, is deny the deleting of the original .jar file.

I think Windows won't let you rename the file that is open at the moment, maybe you need to make a small batch or command file to cleanup and run it after updating?

from ripme.

Latest commit/version (1.0.13) has a "better" updater: 0eba920

• Logs are more verbose and explicit about what the update is doing
• Using apache-commons-io to copy the file over (shouldn't silently fail)
• File copying has retry logic on failure (3 retries, 1-second wait before trying again)
• Opens directory and display error message when unable to copy updated file over.

Granted, you'll probably need to manually upgrade to this version... Crap, there's no way to test until there's a new version. I didn't really think this through...

from ripme.

Yeah, not sure if it matters but here's what happens if I update now:

2014-04-09 13:42:07,182 1379 [AWT-EventQueue-0] DEBUG ui.UpdateUtils - oldVersion 1.0.11 < latestVersion1.0.13
2014-04-09 13:42:08,594 2791 [AWT-EventQueue-0] INFO ui.UpdateUtils - New version found, downloading...
2014-04-09 13:42:19,549 13746 [Thread-4] INFO utils.Utils - Saved configuration to D:\ripme\rip.properties
2014-04-09 13:42:19,643 0 [main] INFO ripme.App - Initialized ripme v1.0.13
2014-04-09 13:42:19,644 1 [main] INFO ui.UpdateUtils - Updated .jar file 'ripme.jar.update' exists, overwriting older version at ripme.jar ...
2014-04-09 13:42:19,655 12 [main] INFO ui.UpdateUtils - Will delete 'ripme.jar.update' on exit
2014-04-09 13:42:19,655 12 [main] INFO ui.UpdateUtils - Executing: java -jar ripme.jar
2014-04-09 13:42:19,659 16 [main] INFO ui.UpdateUtils - Started new version at ripme.jar, quitting current program...
2014-04-09 13:42:19,755 0 [main] INFO ripme.App - Initialized ripme v1.0.13
2014-04-09 13:42:19,756 1 [main] INFO ui.UpdateUtils - Updated .jar file 'ripme.jar.update' exists, overwriting older version at ripme.jar ...

ripme.jar stays up but becomes 0 bytes
ripme.jar.update stays up full size
the program does not auto-launch after auto-update (it used to)

I'll try again with 1.0.14.

I thought this might be something about my OS (Win8.1-64), so I tried on a relatively clean Win7 VM. Same results.

from ripme.

Also repro'd on windows.

ripme.jar is 0 bytes

ripme.jar.update is full size, not deleted on exit.

Noticed this thread: flapdoodle-oss/de.flapdoodle.embed.mongo#23

Looks like an batch/shell script to update everything is the appropriate solution.

from ripme.

I hate shell/batch scripting.

Tested on Win7 & OSX Lion.

Note that on Win7, the script does not delete the update_ripme.bat file until after RipMe is exited.

Planning to push out 1.0.16 later tonight/tomorrow to fix a separate issue, so hopefully we can confirm if the updater works as expected.

from ripme.

Just updated from 16 to 17, everything peachy.

from ripme.

Good to hear it's working. Reopen or create a new issue if there's problems in the future.

from ripme.