After dlopen delete the file
Gayanath
file from the disk ,and update it with a new
version. Is it possible? I'm opening the library using RTDL_NOW flag.
Jens Thoms Toerring
I guess it's not different from deleting a file you still have
open - it won't be visible anymore (and a new fle with the same
name can be created) but it will still exist until you close it.
I'm rather sure the old version of the library will be usable
while you still have the handle, i.e. until you do a dlclose()
on it, regardless of your replacing the file by a new version.
Regards, Jens
--
\ Jens Thoms Toerring ___ j...@toerring.de
\__________________________ http://toerring.de
Gayanath
Måns Rullgård
> Gayanath <gayanat...@yahoo.com> wrote:
>> I have to open a library using dlopen , and then remove the library
>> file from the disk ,and update it with a new
>> version. Is it possible? I'm opening the library using RTDL_NOW flag.
>
> I guess it's not different from deleting a file you still have
> open - it won't be visible anymore (and a new fle with the same
> name can be created) but it will still exist until you close it.
> I'm rather sure the old version of the library will be usable
> while you still have the handle, i.e. until you do a dlclose()
> on it, regardless of your replacing the file by a new version.
Your guess is correct, at least on Linux and Solaris. I'd be
surprised if other Unix variants were any different.
The one thing I can think of that might be different is if you
dlopen() a library, replace the file, and dlopen() it again without
closing the first handle. Doing this is probably not a good idea
anyway.
--
Måns Rullgård
ma...@mansr.com
Barry Margolin
Måns Rullgård <ma...@mansr.com> wrote:
> j...@toerring.de (Jens Thoms Toerring) writes:
>
> > Gayanath <gayanat...@yahoo.com> wrote:
> >> I have to open a library using dlopen , and then remove the library
> >> file from the disk ,and update it with a new
> >> version. Is it possible? I'm opening the library using RTDL_NOW flag.
> >
> > I guess it's not different from deleting a file you still have
> > open - it won't be visible anymore (and a new fle with the same
> > name can be created) but it will still exist until you close it.
> > I'm rather sure the old version of the library will be usable
> > while you still have the handle, i.e. until you do a dlclose()
> > on it, regardless of your replacing the file by a new version.
>
> Your guess is correct, at least on Linux and Solaris. I'd be
> surprised if other Unix variants were any different.
Aren't there some Unix flavors that return ETXTBSY if you try to delete
an executable file that's in use? These might do the same thing for
shared libraries.
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
David Schwartz
> Aren't there some Unix flavors that return ETXTBSY if you try to delete
> an executable file that's in use? These might do the same thing for
> shared libraries.
Nope. There is no such thing as a "delete a file" operation on UNIX.
There is only an option to remove a file from a directory, and that is
logically an operation on the directory, so whether or not the file is
in use should not matter.
On the other hand, they might prevent you from modifying the file.
(Which is better than the normal response to this situation, which is
crashing.)
DS
Paul Pluzhnikov
> On Feb 28, 6:59 pm, Barry Margolin <bar...@alum.mit.edu> wrote:
>
>> Aren't there some Unix flavors that return ETXTBSY if you try to delete
Sure do; HP-UX is the only surviving one in wide use ...
> Nope. There is no such thing as a "delete a file" operation on UNIX.
> There is only an option to remove a file from a directory, and that is
> logically an operation on the directory, so whether or not the file is
> in use should not matter.
Maybe in theory it shouldn't matter, but in practice it matters
very much:
$ uname -sr
HP-UX B.11.11
$ echo "int main() { sleep(60); return 0; }" | gcc -xc -
$ ./a.out & rm -f ./a.out
[1] 9132
rm: ./a.out not removed. Text file busy
Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
Barry Margolin
Paul Pluzhnikov <ppluzhn...@charter.net> wrote:
> "David Schwartz" <dav...@webmaster.com> writes:
>
> > On Feb 28, 6:59 pm, Barry Margolin <bar...@alum.mit.edu> wrote:
> >
> >> Aren't there some Unix flavors that return ETXTBSY if you try to delete
>
> Sure do; HP-UX is the only surviving one in wide use ...
>
> > Nope. There is no such thing as a "delete a file" operation on UNIX.
> > There is only an option to remove a file from a directory, and that is
> > logically an operation on the directory, so whether or not the file is
> > in use should not matter.
>
> Maybe in theory it shouldn't matter, but in practice it matters
> very much:
>
> $ uname -sr
> HP-UX B.11.11
>
> $ echo "int main() { sleep(60); return 0; }" | gcc -xc -
> $ ./a.out & rm -f ./a.out
> [1] 9132
> rm: ./a.out not removed. Text file busy
And back to the reason I brought this up: does HP-UX also prohibit
removing shared objects that are in use?
Paul Pluzhnikov
> And back to the reason I brought this up: does HP-UX also prohibit
> removing shared objects that are in use?
One would expect it to. Checking...
$ echo "int foo() { return 42; }" | gcc -shared -fPIC -o foo.sl -xc -
$ echo "int main() { sleep(60); return foo(); }" | gcc ./foo.sl -xc -
$ ./a.out & sleep 1; rm -f ./a.out ./foo.sl
[1] 2576
rm: ./a.out not removed. Text file busy
rm: ./foo.sl not removed. Text file busy
Note: sleep 1 is needed because without it "rm" wins the race
against dynamic loader, and the executable fails to start:
$ ./a.out & rm -f ./a.out ./foo.sl
[1] 3665
rm: ./a.out not removed. Text file busy
/usr/lib/dld.sl: Can't open shared library: /home/paul/./foo.sl
/usr/lib/dld.sl: No such file or directory
[1]+ ABORT instruction (core dumped) ./a.out
$