one of our research groups wants to use ELAN. They use our group network storage to store the eaf files. They realized that ELAN does not use any kind of locking mechanism. So it is possible that two people from different computers open the same file simultaneously. If they save it the last one wins, the other one’s changes are lost.
I would recommend some sort of file locking if an eaf file is opened. To make these locks as portable as possible I would only use a simple mechanism like the creation of a file, something like “.originalfilename.eaf.lock” (which may contain date, hostname and username of the lock holder). If somebody tries to open an already locked file, ELAN could simply display the content of the lock file.
Yes, this issue has been raised by other users as well recently, so we added it to the to do list.
I don’t know yet what the actual implementation would look like, but if possible I would prefer the use of a built-in Java file locking mechanism, but I didn’t really look into that yet.
I am no Java programmer, but a quick search brought me up with java.nio.channels.FileLock which is the preferred built-in Java file locking mechanism. But the problem with this mechanism is that it depends on the operating system’s native locking mechanism and often fails on network file systems.
As ELAN is platform independent the locking mechanism should also try as hard as possible to be it. If people use network file systems across operating system boundaries (we do) they will also want locking across file system boundaries (we do). So in my opinion the native Java locking mechanism is no option.
Hi,
I have implemented the locking mechanism described by @odenbach: If someone opens a eaf File a File called “.originalfilename.eaf.lock” will be created and populated with a time stamp, the username and the hostname of the computer. If now someone tires to open the same file the user will get an error message like “This file is since 15.08.2018 11:51:42 opened by cschenk on cschenks-computer”.
I didn’t have time yet to look into this matter of file locking in general and I only had a quick look at your implementation, so far.
In general I’m not too enthusiastic about this lock file approach; it doesn’t prevent an .eaf file from being edited in another application and I guess the lock file won’t be deleted in case of a crash of ELAN.
More specifically to your implementation, it seems that the file is being locked in TrancriptionImpl and unlocked when the ELAN frame is closed. But TranscriptionImpl is loaded in e.g. many multiple file operations (e.g. statistics for multiple files), without being made visible, and I guess locking isn’t needed in those situations but also the lock file probably won’t be deleted in such situations (I didn’t test this).
A smaller problem is that we’re still bound to Java 1.6…
this lock file approach is quite common - even the vi editor uses it. If you open a file with vi and try to open the same file on another host with vi you get a warning. But the lock file does not prevent you from opening the file in another editor. Microsoft Office also uses such a scheme.
Preventing files from being opened generally is rather difficult and needs support from the underlying operating system and file system. But as ELAN is platform independant this is not possible as locks must also be made platform independant.
So please have a closer look at this locking mechanism. I am convinced that this is the only way platform independant locking is possible at all.
i have ported my Patch for ELAN version 5.3
You can find it right here: https://github.com/chschenk/ELAN/pull/3
Also i have changed the patch so that it runs with Java 1.6
I would like to hear what you think about this one.
we had some feedback on our patch. It works well on Linux and Windows, but MacOS computers fail to open and initialize ELAN files correctly. Do you know of anything special about opening files on MacOS X?
we use this patch in our group on Mac`s and Windows and it works very well. Without the “locking mechanism” we lost a lot of data. Now it’s almost impossible to work on one file at the same time by accident. So, we don’t have trouble with losing data anymore. It is a big improvement for ELAN!!!
OK, my colleague found out that MacOS X still uses Java 1.6, so he changed his patch to work with that, now ELAN works with file locking - independant from neither platform or network file system.
I’ve tested the patch on linux, it works fine when opening and closing files on the server. However, it messes up when working locally. When opening and closing the files, I was not able to open them again. That is, an empty file with the same name was opened instead. This happened within a session as well as after restarting ELAN. So apparently, the patch locks the local data once but does not release the file again.
Hi oabramov,
I can’t reproduce your error ELAN works fine on my linux machine both on my local and on a network filesystem. My patch does not differentiate between network and local filesystems which makes me wonder why my patch is not working on your local filesystem but on your server. The way my patch locks a file is by creating a lockfile called “.$FILENAME.lock” for example “.test.eaf.lock”. If ELAN is closed normally the lockfile will be deleted and the file is unlocked again. However, if ELAN wasn’t closed normally the lockfile will not be deleted and so the file won’t be unlocked. Maybe this was the case in your tests? To solve this problem just manually delete the lockfile and you should be able to open the file again. If this is not your problem it would be interesting to know which java version you have installed on your system.
thank you for answering. I’ve checked your suggestion and indeed, the patch creates a .lock file in my directory, however, the .lock file is still there when I close the file and ELAN. I don’t used the installer for ELAN but compiled it from source, that might be the point. That is, I’ve downloaded the source folder and compiled ELAN via maven. Perhaps the error can be reproduced if you try this too.
Hi Olga,
even if i compile ELAN via maven i can’t reproduce your error. Have you downloaded the latest source code from https://github.com/chschenk/ELAN/tree/feature-filelocking-5.3 ? If you are using the latest version of my patch what java version do you use?
now, I’ve taken the latest release and the re-opening of the file works fine, so after closing I can open it again. However, the lock-file once created is not deleted and I can open the file with multiple instances of ELAN, even when should be locked. is that normal?
My java-version:
java -version
java version “1.8.0_191”
Java™ SE Runtime Environment (build 1.8.0_191-b12)
Java HotSpot™ 64-Bit Server VM (build 25.191-b12, mixed mode)
Hi Olga,
no that is not an expected behavior. Can you describe your setup and how you are testing the Patch? Are you using two different machines or just your local machine? If you use two different machines do you use the latest patch on both machines? If you are just testing on your local machine is your file located on a network share or on your local hard disk? And how do you open the two instances of ELAN?
