saving projects and files

Jalview Discussion
1

Hi,

I often work by mobile computing on a jalview alignment.
At work I have an extra monitor attached to my laptop and after
disconnecting that and putting the whole shebang to sleep some java
programs (LibreOffice, JalView) appear to hang upon resume in absence
of this extra monitor. I do not know whether it has to do with my DE
(xfce, which has recently been upgraded to 8.12, since when these
crashes seem to occur more often), but now I have lost a large portion
of work due to such a java crash. And that when I thought I had saved
my project half an hour before disconnecting at work.

My project had two large alignment files and the one I had been working
on this week has gone, disappeared completely. During resume I got a
blank Jalview frame and I closed the program. The generated java-crash
file starts with:
# A fatal error has been detected by the Java Runtime Environment:
# SIGSEGV (0xb) at pc=0x00007f5a085ddbf4, pid=1281, tid=140024677439296
# JRE version: Java(TM) SE Runtime Environment (8.0_45-b14) (build
1.8.0_45-b14) # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.45-b02
mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C [libpthread.so.0+0x9bf4] pthread_mutex_lock+0x4

What I found though, is that the files within the project
ALSO had not been saved. I had pressed 'Save file' in the menus of
each of the alignment-files to be sure this would happen but this had
not done anything. Or does this only save the file within the jvp
archive??? If so, for me this is not the expected behaviour as I
originally loaded these files into the project from a particular
folder on my disk and when I save these files I expect them to be
written to the same folder as where they originated from....

I find that only by "Save file as", a recent update can get written to
the place of choice from within a project. But this is quite
cumbersome.

Am I the only one experiencing this behaviour?

For me expected UI-behaviour would be:

1) Whenever/whatever Safe is chosen the file in question should be
written to disk (outwith the jvp-archive unless the project itself is
saved), overwriting the older version.

2) Also, as a user, when saving a project I assume (wrongly as it turns
out) that with the project the separate files in the project will get
saved too, overwriting the original source files. This does not happen.
Everything, as I understand it, is packed into the jvp archive and only
there. Thus the files in the project are out of sync with the
original files on disk. Thus, if the jvp is corrupted all work is gone.

I think that, when this is the normal behaviour of JalView, a large
improvement is possible here.

What do people think?

···

--
Dr. R.W. van Nues

SYNTHETIC and SYSTEMS BIOLOGY at EDINBURGH (SynthSys)

The University of Edinburgh
CH Waddington Building
Max Born Crescent
Edinburgh EH9 3BF

Telephone +44 (0)131 651 9018
E-mail:rob.van-nues@ed.ac.uk

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

2

Hi Rob, thanks for letting us know about the resume-hang issue.

I'd really appreciate it if you could file a bug report about that over at issues.jalview.org and we'll look into it. On Macs, X seems to just about cope with relocating windows, but I've not had too much experience with Xorg and moving between different display environments.

Regarding the "Save file" option, I'd just like to clarify something: Did you load the alignments from their original files or did you open the set of alignments from a .jvp file you'd saved earlier ?

The reason I ask is as currently coded, If you load a file into Jalview, the 'Save file' option should write back to the same file again (although it might do things like tweak the sequence ID format... which we really ought to fix!). However, "Save file" in the context of an alignment opened from a jvp project that you loaded back into Jalview will (or at least should) update your project file, rather than attempt to write back to the original file. Either way, no data should have been lost (but it sounds like it has!).

I can see the utility of having Jalview write back to the original files in place - in fact, it's pretty much mandatory if we are to have Jalview work with alignment files too big to import into memory. I'm just trying to get my head around the idea that Jalview may also need to provide the option to 'update original file' as well as archiving the current state as a project.

Jim.

···

On 06/05/2015 22:40, rob van nues wrote:

Hi,

I often work by mobile computing on a jalview alignment.
At work I have an extra monitor attached to my laptop and after
disconnecting that and putting the whole shebang to sleep some java
programs (LibreOffice, JalView) appear to hang upon resume in absence
of this extra monitor. I do not know whether it has to do with my DE
(xfce, which has recently been upgraded to 8.12, since when these
crashes seem to occur more often), but now I have lost a large portion
of work due to such a java crash. And that when I thought I had saved
my project half an hour before disconnecting at work.

My project had two large alignment files and the one I had been working
on this week has gone, disappeared completely. During resume I got a
blank Jalview frame and I closed the program. The generated java-crash
file starts with:
# A fatal error has been detected by the Java Runtime Environment:
# SIGSEGV (0xb) at pc=0x00007f5a085ddbf4, pid=1281, tid=140024677439296
# JRE version: Java(TM) SE Runtime Environment (8.0_45-b14) (build
1.8.0_45-b14) # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.45-b02
mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C [libpthread.so.0+0x9bf4] pthread_mutex_lock+0x4

What I found though, is that the files within the project
ALSO had not been saved. I had pressed 'Save file' in the menus of
each of the alignment-files to be sure this would happen but this had
not done anything. Or does this only save the file within the jvp
archive??? If so, for me this is not the expected behaviour as I
originally loaded these files into the project from a particular
folder on my disk and when I save these files I expect them to be
written to the same folder as where they originated from....

I find that only by "Save file as", a recent update can get written to
the place of choice from within a project. But this is quite
cumbersome.

Am I the only one experiencing this behaviour?

For me expected UI-behaviour would be:

1) Whenever/whatever Safe is chosen the file in question should be
written to disk (outwith the jvp-archive unless the project itself is
saved), overwriting the older version.

2) Also, as a user, when saving a project I assume (wrongly as it turns
out) that with the project the separate files in the project will get
saved too, overwriting the original source files. This does not happen.
Everything, as I understand it, is packed into the jvp archive and only
there. Thus the files in the project are out of sync with the
original files on disk. Thus, if the jvp is corrupted all work is gone.

I think that, when this is the normal behaviour of JalView, a large
improvement is possible here.

What do people think?

3

Hi Rob.

So you would also find it even more useful if we included an 'update
original file' option ?

Yes, that would be very helpful but would that not need to be something
triggered automatically when saving the project instead of a separate
(menu) option? This depends of course how people experience this, but it
might create too many save options (safe project, safe file, save file
as, update original). It took me, as user, a while to figure out that
project-saving does not touch the files I started of with. When I safe
I think that the file I started with is overwritten. The problem is
associated with the fact that the title-bar of the alignment in the
project still carries the full-path/original file-name thus one expects
that to be the destination of 'safe'.

Yes. Jalview's alignment titles have never been used in that way - since new alignments/predictions are created with a more complex title to indicate what created them. We will phase out that behaviour in Jalview 3, however. Most likely, titles in Jalview 3 will be either the physical location of the data or - if the source format allows it, some user editable string (optionally indicating it's physical location).

At least 'Safe file, (ctr-S)'
should always do something towards the folder where the file came from
(i.e. following the path in the title-bar). That would be my expected
behaviour.

CTRL/CMD-S always saves to the last saved location.

  So the option you speak of should be linked to the save
(file) command without being visible to the user. I think that would
keep the interface intact. Save project is save project and save file
is save file to its original destination; not (only) within the project.

Perhaps. I think we'll need to explore how this can work with a prototype. I suspect that in the [farther] future we may even do away with the concept of saving projects all together, and have Jalview automatically persist the session whilst you work. Then, updating an external file or exporting to a (new) project will be explicit actions.

Another safeguard would be if automatically the old version of the file
is kept as backup (with ~ or another file-extension) as vim does.

good idea ! We had something like this in place in earlier versions of Jalview, but never fully implemented it.

Jim.

···

On 07/05/2015 09:13, rob van nues wrote: