- Posts
I noticed that when I open a file in EE, it may become unreadable for other programs for a while. In my case, the file is a small Perl script located on a virtual machine connected to mine via network. This script is executed regularly (every 1 second) for performing some actions. But when I open this script for editing in EE, sometimes I get an error on the virtual machine:
/home/…/my_script.pl: /usr/bin/perl: bad interpreter: Text file busy
and after that the file continues executing every 1 second without problems. Does EE lock this file at the moment of opening? If yes – how could it be avoided?
Flint wrote:
I noticed that when I open a file in EE, it may become unreadable for other programs for a while. In my case, the file is a small Perl script located on a virtual machine connected to mine via network. This script is executed regularly (every 1 second) for performing some actions. But when I open this script for editing in EE, sometimes I get an error on the virtual machine:/home/…/my_script.pl: /usr/bin/perl: bad interpreter: Text file busy
and after that the file continues executing every 1 second without problems. Does EE lock this file at the moment of opening? If yes – how could it be avoided?
It depends on settings. On File tab of Configuration Properties, if “Keep Locked” is selected for the “Changed by Another Program” drop-down list, your file can be locked from another program. Also, if the file size is larger than 300 MB (by default, or can be set at the Advanced tab of Customize dialog box), it can also be locked. These locks mean “exclusive write” but “share read” by EmEditor, and so another program should still be able to “read” the file while EmEditor locks the file. However, some old programs may not be able to open a file as proper share/exclusive options, so you might need to set “None” or “Prompt” for “Changed by Another Program” drop-down list.
The problem is that “Changed by Another Program” setting is already set to Prompt for all my configurations, and the file I’m opening is definitely less than 300 MB – it’s just a usual small Perl file (23 Kbytes in size, actually).
And, besides, if it were one of the options you just mentioned, the file would be locked all the time it is opened in EmEditor (or did I misunderstand something?), while in my situation it is locked for very short period of time – only when it is being opened by EE, and after it is loaded into EE, the file becomes fully accessible again, even though it is shown in EE window. So, it must be not the lock you were talking about, it’s something else…
Flint wrote:
The problem is that “Changed by Another Program” setting is already set to Prompt for all my configurations, and the file I’m opening is definitely less than 300 MB – it’s just a usual small Perl file (23 Kbytes in size, actually).And, besides, if it were one of the options you just mentioned, the file would be locked all the time it is opened in EmEditor (or did I misunderstand something?), while in my situation it is locked for very short period of time – only when it is being opened by EE, and after it is loaded into EE, the file becomes fully accessible again, even though it is shown in EE window. So, it must be not the lock you were talking about, it’s something else…
EmEditor does not open a small file exclusively if “Prompt” is set. So, it is possible that your Perl program does not open with “read-share” option. Can you please try with Notepad and the problem still exists?
Can you please try with Notepad and the problem still exists?
Hm… It’s not an easy task to open a file in Notepad every second… I’ll try to find some other way to check the access to the file.
Can you tell absolutely sure whether type requires file lock, and if yes – which type of lock? Originally, I had almost the same situation as you suggested, the only difference is that I’m using Perl interpreter, not type command. So, I need something more open for analysis. Maybe, I’ll just write a simple program for that…
Well, here are the results of the first part of my tests.
1. First of all, it is not Perl interpreter who drops the error. It is Bash. I started my PL-script by simple calling it via ./my_script.pl, and when I changed it into explicit call of perl (/usr/bin/perl ./my_script.pl) the error no longer appears. However, it does not solve anything. I tried also to look through the source code of Bash interpreter to find the conditions on which it drops this error, but there was no such error message…
2. I tried to reproduce the problem using Notepad instead of EmEditor – but failed. I tried to do it about 30-40 times, and no error appeared, while with EmEditor it appears after approximately every 4-5 openings.
3. I tried to write a program that runs on the virtual machine and constantly tries to open and close the file with read-write access, and while this program was running tried to open the file in EmEditor – and again, no problem appeared. :-(So, all this seems as if EmEditor during opening a file set a very specific lock, which causes Bash (and only Bash) to fail opening the same file at the same moment. After EE read the file into memory, it releases the lock, but it’s too late – Bash already failed to open the file.
Moreover, I also tried to set the option “Changed by Another Program” to “Keep Locked” – and even then the file was correctly opened and executed by Bash+Perl! So, the lock while opening a file and the lock after it’s opened are two completely different locks.
I’ll be trying further…
Flint wrote:
Well, here are the results of the first part of my tests.
1. First of all, it is not Perl interpreter who drops the error. It is Bash. I started my PL-script by simple calling it via ./my_script.pl, and when I changed it into explicit call of perl (/usr/bin/perl ./my_script.pl) the error no longer appears. However, it does not solve anything. I tried also to look through the source code of Bash interpreter to find the conditions on which it drops this error, but there was no such error message…
2. I tried to reproduce the problem using Notepad instead of EmEditor – but failed. I tried to do it about 30-40 times, and no error appeared, while with EmEditor it appears after approximately every 4-5 openings.
3. I tried to write a program that runs on the virtual machine and constantly tries to open and close the file with read-write access, and while this program was running tried to open the file in EmEditor – and again, no problem appeared. :-(So, all this seems as if EmEditor during opening a file set a very specific lock, which causes Bash (and only Bash) to fail opening the same file at the same moment. After EE read the file into memory, it releases the lock, but it’s too late – Bash already failed to open the file.
Moreover, I also tried to set the option “Changed by Another Program” to “Keep Locked” – and even then the file was correctly opened and executed by Bash+Perl! So, the lock while opening a file and the lock after it’s opened are two completely different locks.
I’ll be trying further…
I tried to reproduce your problem here, but I coldn’t. EmEditor works as it is supposed to.
I created a test program, which opens a test file with GENERIC_READ | GENERIC_WRITE access and FILE_SHARE_READ share every 100ms, and alerts if it fails to open a file.
I also created a macro which opens the same file within EmEditor every 9 ms. When both run, nothing happens until I stop them. If the test program opens the file without FILE_SHARE_READ share, then conflict appears.The test program I used is C++:
for(;;){
HANDLE hFile = CreateFile( _T("E:testtest.txt"), GENERIC_READ | GENERIC_WRITE, FILE_SHARE_READ, NULL, OPEN_ALWAYS, 0, NULL );
if( hFile == INVALID_HANDLE_VALUE ){
if( MessageBox( NULL, _T("CreateFile error."), NULL, MB_OKCANCEL ) != IDOK ){
return 1;
}
}
CloseHandle( hFile );
Sleep(100);
printf( _T(".") );
}
The macro I used for EmEditor is JavaScript for EmEditor:
editor.NewFile();
for( i = 0; i < 10000; i++ ){
document.write(".");
editor.OpenFile( "E:TestTest.txt", eeEncodingSystemDefault, eeOpenDetectUnicode | eeOpenAllowNewWindow );
document.close();
Sleep( 9 );
}
- You must be logged in to reply to this topic.