Re: [icedtea-web][rfc] Fix of backup of deployment.properties onsome OSs

[Jacob Wisor]

"Jiri Vanek"<jvanek at xxxxxxxxxx> wrote:
> On 05/07/2013 05:50 PM, Jacob Wisor wrote:
> > "Jacob Wisor"<gitne at xxxxxxxxxxxx> wrote:
> >> Hello!
> >>
> >> Some OSs (e.g. Windows) or file systems do not allow to overwrite while renaming or moving files. It could also depend on the implementation of java.io.File.renameTo(java.io.File), as its specification leaves open the exact semantics.
> >>
> >> Although the proposed fix is not really elegant, it should work on the majority of systems. Maybe the whole idea of renaming deployment.properties to always have a safe backup is just 
> 
> agree
> 
> >> redundant on modern operating and file systems, since most of them feature journaled or transactional file systems, so there should always be a safe copy having integrity available.
> >>
> >> Happy reviewing!
> >> Jacob
> > 
> > Sorry, the webmailer keeps dropping attachements at random...
> > 
> Hi! The patch looks ok, however I'm in doubts whether this quite complex solution is necessary.
> What I have in mind is:
> 1) Does .old file exists? If yes, delete it. (if it is directory then... ??? :))  I think we can
> ignore this case. If Deletion failed, warn user and log exception(if none, then jsut some stderr
> stuff)  (there would be nice some better error reporting - in comamndline mode[1] just print
> exception, whether in gui[2] mode also show dialogue, but do not throw exception out - but it is
> probably work for different changeset)

Right, deployment.properties.old can be deleted right away. I wanted to make sure that the backup file is also safe until the "renaming operation" is complete. This kind of mimiks the renaming semantics as originally intended.

> 2)Rename current properties to .old  - if it failed - again warn, but do not fail - maybe ask the
> user to continue - not continue (in gui mode).
> 3) save  new properties - if this failed - then this is the only reason for fatal exception imho.

I am not sure whether I understand you correctly. The proposed solution only fails when the properties file can not be backed up and though the application keeps on running, the settings do not get saved. Yeah, there probably should be just a notice on stderr or the UI. In any case, the application should keep on running as this seems to me to be the expected intuitive behavior. So, I would rather keep the user unbothered, since he/she can close the application at any time or keep on running anyway.
 
> What do you think?
> 
> If you agree, then for now only the parts without the "user interactions" are worthy. But of course
> if you are wiling to fix also the interaction then we will be more then happy (but please as
> different changeset)
> 
> Thank you for checking this!
> 
> J.
> 
> 
> [1]
> http://icedtea.classpath.org/hg/icedtea-web/file/9f2d8381f5f1/netx/net/sourceforge/jnlp/controlpanel/CommandLine.java
> [2]
> http://icedtea.classpath.org/hg/icedtea-web/file/9f2d8381f5f1/netx/net/sourceforge/jnlp/controlpanel/ControlPanel.java

Thank you for the guiding references.

Jacob