Is it possible for ELAN to work with a read-only and a writeable version of the same corpus?

(I’m posting on behalf of a new colleague, Xifong, because as a new forum member, his post is awaiting review.)

Hello, I’m working on the BSL corpus. The team are looking to have a file locking mechanism for our .eaf files, however, when searching multiple .eafs for particular features, we wouldn’t want to lock all of the files in the domain, since others should be able to access them unless they are being edited.

We understand that version 5.8 has a file locking mechanism (we’re currently using 5.5) but since it is only for files opened from the main ELAN window, that wouldn’t cover this scenario. We hit upon a potential option which would be to have two separate locations (available to the standard system file picker) that allowed access to the same corpus data, a read-only one and an editable one. Only the editable one would thus require locking (this locking is to be managed by our data storage solution).

In this way, we would perform searching (and anything else that required no alterations) on the read-only location without locking any files. However, we would like to be able to edit files chosen from the search results - the way ELAN can jump directly to part of the video/eaf where the search feature is found, is extremely useful to us.

In this case, is there any way for ELAN to give us more choice as to where the files selected from the search results are taken from, so that we could optionally get the file from the location where it is editable, as opposed to where the search was done initially?

I’d greatly appreciate any guidance on how this might be achieved or whether or not it is possible. Perhaps, this is a query that another team has had in the past? If so it would be useful to learn from their experience. Also, I’d be happy to provide further explanation if that would be helpful.

Hello, first of all apologies for the delay in the review of Xifong’s post, it has just been approved.

To start with your last question, I don’t think there is a way in ELAN now to more or less redirect ELAN from a hit in the search results to the same file and fragment but in a different location. There is no “in memory” replace of the file path by a different path.

In your first paragraph you mention that you don’t want to lock all files in the domain when doing a search or similar. That is how the (simple) locking mechanism of 5.8 works: files are not locked when searching, others are able to access the files. But this means that others can also make changes to the files that are being searched.

I think in both cases, performing the search on the corpus that can be edited or performing the search in a read-only mirror location, there is the possibility of a mismatch or inconsistency when trying to jump from a search hit to that location opened in ELAN: the “hit” annotation might not be there anymore, might have been moved or its contents might have been changed. So even if it were possible to do a “redirect jump” you could run into this kind of situations.

Maybe you can execute your queries in a “frozen” version of the corpus and if you run into something that needs to be changed, execute the same query again in the “live” version of the corpus and make the changes?


Hello Han, thank you for your response. Also, thanks for your clarification of the lock system, I’ll give that a try and we’ll have a think about performing a second query onto the “live” corpus.

Hi Han, just to clarify, when the search function is used and a file is selected from the search results, will that file be locked (so long as the preference is enabled)? Also, am I correct in the belief that locks will affect all users, not just those with the preference checked?


Hello Xifong,

“Yes” to both questions (in both cases ELAN 5.8 or 5.9 are assumed).


Hi Han, thanks for your answer.