Hello.
I am having a small problem removing the default original binary for vi
that is found in both the /bin and /usr/bin directories. I had just
installed Vim and wanted to create a symbolic link of vi to vim. Upon
trying to do this (as root), I got error messages that indicated that it
could not be unlinked or removed. I then tried to remove it using rm
and got the following similar message: “rm: Can’t unlink vi: No such
file or directory.” I get this regardless of whether I do:
rm vi (in the directory)
rm ./vi
rm /usr/bin/vi
I have tried using the -f option to the rm, but that didn’t work
either. Does anyone know why this would be happening and how I can
remove this?
Thanks.
Rodney Lott
Rodney Lott <rod@fuelcelltechnologies.ca> wrote:
: Hello.
: I am having a small problem removing the default original binary for vi
: that is found in both the /bin and /usr/bin directories. I had just
: installed Vim and wanted to create a symbolic link of vi to vim. Upon
: trying to do this (as root), I got error messages that indicated that it
: could not be unlinked or removed. I then tried to remove it using rm
: and got the following similar message: “rm: Can’t unlink vi: No such
: file or directory.” I get this regardless of whether I do:
: rm vi (in the directory)
: rm ./vi
: rm /usr/bin/vi
: I have tried using the -f option to the rm, but that didn’t work
: either. Does anyone know why this would be happening and how I can
: remove this?
This is a bug in the package filesystem … the creation
of symbolic link entries on top of files that are handled
by the package filesystem is problematic and an appropriate
fix is being investigated.
What is reported with pkgctl /usr/bin/vi or pkgctl /bin/vi?
Can you take a look at the contents of /var/pkg/spill
and see if x86/bin/.fspkg-spill exists, and if so what
the contents are.
For those interested in the details, the package filesystem
performs a re-direction to a “spill area” (/var/pkg/spill)
for files which are handled by the PFS but have been modified
(including removal) by the user. When you attempt to create
an entry of any type on top of a spilled entry, then that
request is forwarded to the spill location. This is fine if
you are replacing the spilled entry with a similar entry, but
not so good if you are changing the type of the entry (ie
link->file, file->link, anything->directory etc). As a
result we also cascade through the filesystems (which is
why you need backing store) so that we can provide support
for extended operations. Links fall through the cracks
unfortunately.
The bug in the package filesystem that prevents you from
removing the symbolic link properly has been fixed.
Unfortunately the creation of the new link is still a
problem. For now I would advise you to either copy
vim on top of elvis (option 1), use the /proc/mount
filesystem to place copies of vim in /usr/bin and /bin
(or create the appropriate symlinks) and then remove
the /bin/vi and /usr/bin/vi links (option 2 with the
new PFS). Create your own package to override the
links (option 3 … no docs on this yet though, see
my other posts on the PFS in various newsgroups).
I recognize this as a major inconvenience and am working
on the problem.
Thomas
Thomas (toe-mah) Fletcher QNX Software Systems
thomasf@qnx.com Neutrino Development Group
(613)-591-0931 http://www.qnx.com/~thomasf
Thomas Fletcher wrote:
snip
This is a bug in the package filesystem … the creation
of symbolic link entries on top of files that are handled
by the package filesystem is problematic and an appropriate
fix is being investigated.
What is reported with pkgctl /usr/bin/vi or pkgctl /bin/vi?
Can you take a look at the contents of /var/pkg/spill
and see if x86/bin/.fspkg-spill exists, and if so what
the contents are.
pkgctl /usr/bin/vi:
— Information from /dev/pkginfo10 —
Localpath: [/usr/bin/vi]
Fullpath: [/pkgs/base/qnx/os/core2.1/x86/bin/elvis]
Repository: [/pkgs/base]
Vendor: [qnx/os/core2.1]
Tree: [x86/bin/elvis]
pkgctl /bin/vi:
— Information from /dev/pkginfo10 —
Localpath: [/bin/vi]
Fullpath: [/pkgs/base/qnx/os/core2.1/x86/bin/elvis]
Repository: [/pkgs/base]
Vendor: [qnx/os/core2.1]
Tree: [x86/bin/elvis]
The contents of the /var/pkg/spill directory contains only two
subdirectories: etc and var. Given that I was making changes to
my /etc/hosts file and that the var directory is used by printing,
I would assume this is not unusual. No x86 subdirectory, though.
The bug in the package filesystem that prevents you from
removing the symbolic link properly has been fixed.
Unfortunately the creation of the new link is still a
problem. For now I would advise you to either copy
vim on top of elvis (option 1), use the /proc/mount
filesystem to place copies of vim in /usr/bin and /bin
(or create the appropriate symlinks) and then remove
the /bin/vi and /usr/bin/vi links (option 2 with the
new PFS). Create your own package to override the
links (option 3 … no docs on this yet though, see
my other posts on the PFS in various newsgroups).
I copied over the vi’s in /usr/bin and /bin and that seems to
work.
I recognize this as a major inconvenience and am working
on the problem.
Thomas
Thomas (toe-mah) Fletcher QNX Software Systems
thomasf@qnx.com > Neutrino Development Group
(613)-591-0931 > http://www.qnx.com/~thomasf