ETXTBSY?
Juliet
--
< http://www.reactos.com/ > Open source clone of Windows NT. Current
Don't stand, REACT! version 0.0.19. C, C++ and ASM developers
and beta testers are welcome!
Ed L Cashin
> Hi all. Can someone please explain me the meaning of this error code?
/usr/src/kernel-source-2.4.18/include/asm-i386/errno.h says:
#define ETXTBSY 26 /* Text file busy */
--
--Ed L Cashin | PGP public key:
eca...@uga.edu | http://noserose.net/e/pgp/
Andrew Gierth
Juliet> Hi all. Can someone please explain me the meaning of this
Juliet> error code?
it means that you're trying to open for writing a file which is
currently being executed as a program, or that you're trying to
execute a file which is currently open for writing.
Not all systems check for this error condition.
--
Andrew.
comp.unix.programmer FAQ: see <URL: http://www.erlenstar.demon.co.uk/unix/>
or <URL: http://www.whitefang.com/unix/>
Malte Starostik
>>>>>> "Juliet" == Juliet <julie...@tiscalinet.it> writes:
>
> Juliet> Hi all. Can someone please explain me the meaning of this
> Juliet> error code?
>
> it means that you're trying to open for writing a file which is
> currently being executed as a program, or that you're trying to
> execute a file which is currently open for writing.
>
> Not all systems check for this error condition.
It seems it not only depends on the OS, but also on the file in question
somehow. Would you happen to know what exactly triggers this error?
I'm overwriting executables that are currently running rather often (with a
newer build), and almost never get an error. Just some - or especially one
- particular program always gives me "Text file busy" when I try to
overwrite it in any way (cp, mv, scp, g++ directly ... ).
TIA,
-Malte, who thinks "Text file" is a damn archaic term to call an executable
:-)
Andrew Gabriel
Malte Starostik <malte.s...@t-online.de> writes:
>> Not all systems check for this error condition.
> It seems it not only depends on the OS, but also on the file in question
> somehow. Would you happen to know what exactly triggers this error?
> I'm overwriting executables that are currently running rather often (with a
> newer build), and almost never get an error. Just some - or especially one
> - particular program always gives me "Text file busy" when I try to
> overwrite it in any way (cp, mv, scp, g++ directly ... ).
ETXTBSY worked fine if you go back before days of NFS.
However, it is impossible to implement the check over NFS.
An NFS server has no idea if any of its clients have a file
open and so can't stop the file being overwritten in the
case of any client having it open for execution.
So, in the transition from SVR3 to SVR4 when networking and
NFS became bundled with the base OS, the ETXTBSY check was
removed to make access to local and remote filesystems
look as similar as possible (mirroring the introduction of
vnodes into System V from SunOS to provide uniform access to
all filesystems in the kernel, and associated with the
introduction of Sun's VM system into System V at release 4).
There may be some non-SVR4 unixs which give ETXTBSY on local
filesystems, but not on remote filesystems.
--
Andrew Gabriel
Consultant Software Engineer
Juliet
>> Hi all. Can someone please explain me the meaning of this error
>> code?
> /usr/src/kernel-source-2.4.18/include/asm-i386/errno.h says:
>#define ETXTBSY 26 /* Text file busy */
You're not the only one that can read a header file in a text editor,
you know. But I have no idea of what it means for a "text file" to be
"busy"
Juliet
> Juliet> Hi all. Can someone please explain me the meaning of this
> Juliet> error code?
> it means that you're trying to open for writing a file which is
> currently being executed as a program, or that you're trying to
> execute a file which is currently open for writing.
thank you. So it's "text" as in .text section of a COFF executable?
Strange that the Unix95 standard still uses this term, as the glossary
defines a "text file" as a "file that contains characters organised
into one or more lines. The lines must not contain NUL characters and
none can exceed {LINE_MAX} bytes in length, including the newline
character [...]". I guess that standard was put together from several
different documents. Let's hope they'll iron out these inconsistencies
in future editions
Ed L Cashin
> Ed L Cashin ha scritto:
>
> >> Hi all. Can someone please explain me the meaning of this error
> >> code?
> > /usr/src/kernel-source-2.4.18/include/asm-i386/errno.h says:
> >#define ETXTBSY 26 /* Text file busy */
>
> You're not the only one that can read a header file in a text editor,
> you know. But I have no idea of what it means for a "text file" to be
> "busy"
Um, OK. Good thing Andrew Gierth told you, or you'd be forced to
remain bitter and ungrateful for the rest of your life.
David Schwartz
> TIA,
> -Malte, who thinks "Text file" is a damn archaic term to call an executable
> :-)
This error usually does not occur with executables but with shared
libraries. Note that an 'mv' should not trigger this problem as it is an
attempt to modify a directory, not a text file.
DS
Barry Margolin
Malte Starostik <malte.s...@t-online.de> wrote:
>-Malte, who thinks "Text file" is a damn archaic term to call an executable
>:-)
The section of memory that contains program code is traditionally called
the "text section". So in this context, "text file" is short for "file
from which the text section is being paged".
--
Barry Margolin, bar...@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
GoogleFox
> Andrew Gierth ha scritto:
>
> > Juliet> Hi all. Can someone please explain me the meaning of this
> > Juliet> error code?
> > it means that you're trying to open for writing a file which is
> > currently being executed as a program, or that you're trying to
> > execute a file which is currently open for writing.
>
> thank you. So it's "text" as in .text section of a COFF executable?
> Strange that the Unix95 standard still uses this term, as the glossary
> defines a "text file" as a "file that contains characters organised
> into one or more lines. The lines must not contain NUL characters and
> none can exceed {LINE_MAX} bytes in length, including the newline
> character [...]". I guess that standard was put together from several
> different documents. Let's hope they'll iron out these inconsistencies
> in future editions
We werent talking about "text files" only "text section". Generically,
"text" is _your_data_, whether it be ASCII/Unicode/whatever.
The "text section" refers to a part of the executable containing
_your_data_,
not physical text, and as distinct from other bits of binary bum-fluff
which are needed as part of the overhead in making the system work.
The language is running out of words - "data" might be better but then
"data" has a specific connotation as well. "text section" means
something to a lot of people and is never considered to be "words and
letters".
Andrew Gabriel
Malte Starostik <malte.s...@t-online.de> writes:
> -Malte, who thinks "Text file" is a damn archaic term to call an executable
>:-)
I always liked ENOTTY - Not a Typewriter
A great shame when that error message was "updated".
Andrew Gierth
GoogleFox> We werent talking about "text files" only "text
GoogleFox> section". Generically, "text" is _your_data_, whether it
GoogleFox> be ASCII/Unicode/whatever.
no, that's nothing to do with the original question.
The "text section" of an executable, and the wording of the "text file
busy" error, come from the use of the term "program text" to refer to
the _instructions_ of the program as distinct from its data.
This usage is confusing and unnecessary ("code" is a perfectly good
alternative name for the "text" section, and "executable file busy"
would be a much better error description).
Barry Margolin
Andrew Gierth <and...@erlenstar.demon.co.uk> wrote:
>The "text section" of an executable, and the wording of the "text file
>busy" error, come from the use of the term "program text" to refer to
>the _instructions_ of the program as distinct from its data.
>
>This usage is confusing and unnecessary ("code" is a perfectly good
>alternative name for the "text" section, and "executable file busy"
>would be a much better error description).
The text section usually contains other stuff besides instructions, such as
literal constants. Basically, everything that's sharable and read-only is
in the text segment, while the data segment contains per-process memory
(e.g. the heap).
But the real explanation is that this is computer jargon that was
established 40 years ago. If you're not familiar with low-level operating
system issues, it's not expected to make any more sense than "Segmentation
violation" and "Bus error" do.