[Dovecot] Small problem with src/lib/mountpoint.c
Greetings -
Whilst playing with getting quotas from NFS-mounted filestores I've
just discovered a slight problem with src/lib/mountpoint.c
I had things working on a Solaris 10 test machine which had the
mailstore mounted 'normally' using an entry in /etc/vfstab.
However when I changed to use the automounter for the mailstore
obtaining the quota broke.
The problem lies with mountpoint_get(). On a 'normally' mounted
filestore this obtains the device_path of the remote filestore in the
form
remoteservername.some.domain:/remote/path
However when the mailstore was automounted I was instead getting back
auto_direct
which is the name of the automounter map we're using.
The /etc/mnttab file has TWO entries for the auto-mounted filestore,
like this:
auto_direct /mailstore/messages/p autofs
direct,ignore,dev=4740014 1184648400
crypt2.york.ac.uk:/vol/vol9/p /mailstore/messages/p nfs
proto=tcp,xattr,dev=4700386 1184668792
Although there are two entries they have different device numbers.
The mountpoint_get() function attempts to guard against this by
checking the device number obtained matches that of the path being
located.
However for some reason I don't understand when getmntent() returns
the FIRST of the above two entries it supplies the device number of
the SECOND. Thus the device numbers match in the mountpoint_get()
test and it thinks it has found the correct entry. This leads to the
device_path being set to the map name -- auto_direct -- instead of
the host:/path
My fix is to add an additional fstype for the test to ignore:
"autofs". The loop skips over any such mounts (along with the
existing tests for "swap" and "ignore").
I'm attaching my minimal patch in case it's of help to anyone else.
(Timo: would it be possible to get this added into the distribution
code if you agree it's right?)
Cheers, Mike Brudenell
-- The Computing Service, University of York, Heslington, York Yo10 5DD, UK Tel:+44-1904-433811 FAX:+44-1904-433740
- Unsolicited commercial e-mail is NOT welcome at this e-mail address. *
participants (1)
-
Mike Brudenell