Unexpected behavior when given relative pathnames.
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
unionfs-fuse (Ubuntu) |
Fix Committed
|
Undecided
|
Bernd Schubert |
Bug Description
Binary package hint: unionfs-fuse
Unionfs-fuse does strange things when I tell it to create a union of two directories, and I specify them via relative pathnames. I look into the resulting directory and I see the root filesystem.
To recreate the problem:
$ cd $HOME
$ mkdir foo bar gleep
$ echo one >foo/one
$ echo two >bar/two
$ unionfs-fuse -o cow foo=RW:bar=RO gleep
$ ls gleep
bin etc lib media root sys vmlinuz
boot home lib32 mnt sbin tmp vmlinuz.old
cdrom initrd.img lib64 opt selinux usr xorg.conf.new
dev initrd.img.old lost+found proc srv var
$
Of course, what we expected to see was "one" and "two".
You can get that by using absolute pathnames:
$ fusermount -u gleep
$ unionfs-fuse -o cow $HOME/foo=
$ ls gleep
one two
$
These two invocations should be equivalent. Therefore, there is a
bug in the way unionfs-fuse handles relative pathnames.
ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: unionfs-fuse 0.23.hg.20090611-1
ProcVersionSign
Uname: Linux 2.6.35-24-generic x86_64
NonfreeKernelMo
Architecture: amd64
Date: Tue Dec 14 19:58:44 2010
EcryptfsInUse: Yes
InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release amd64 (20091027)
ProcEnviron:
PATH=(custom, user)
LANG=en_GB.utf8
SHELL=/bin/bash
SourcePackage: unionfs-fuse
Changed in unionfs-fuse (Ubuntu): | |
status: | New → In Progress |
assignee: | nobody → Bernd Schubert (aakef) |
status: | In Progress → Fix Committed |
Please use a more recent version, e.g. from my Launchpad. Sorry, I have no time to push a new version into Debian till at least mid of January (it fails to upload due to a dependency problem with kfreebsd, which also then blocks a ubuntu upload).
https:/ /launchpad. net/~aakef/ +archive/ ppa