jra at samba.org
Wed Apr 17 14:35:09 MDT 2013
On Wed, Apr 17, 2013 at 02:26:21PM -0500, Sam Lang wrote:
> On Wed, Apr 17, 2013 at 2:19 PM, Jeremy Allison <jra at samba.org> wrote:
> > On Tue, Apr 16, 2013 at 11:50:53AM -0700, Jeremy Allison wrote:
> >> On Tue, Apr 16, 2013 at 10:13:46AM -0700, Jeremy Allison wrote:
> >> > On Tue, Apr 16, 2013 at 10:51:13AM -0500, Sam Lang wrote:
> >> > > I still have one failing test from smbtorture on the ceph vfs module.
> >> > > base.open.ctemp test fails with EPERM. It looks like reply_ctemp() in
> >> > > source3/smbd/reply.c is doing a mkstemp with the path returned by
> >> > > realpath, so in the ceph case, its doing: mkstemp("//TMXXXXXX")
> >> > >
> >> > > Unsurprisingly, that fails. On a local filesystem (such as a
> >> > > directory like /tmp/foo), realpath resolves the path to
> >> > > /tmp/foo/TMXXXXXX. But with ceph, no separate mountpoint exists
> >> > > locally. How is ctemp meant to be handled by backend vfs modules that
> >> > > don't have a separate mount running on the smbd server?
> >> >
> >> > Oh, you just found a bug in the VFS :-). Thanks !
> >> >
> >> > reply_ctemp() is a *really* old DOS-style call
> >> > that no modern clients do.
> >> Just to be clear, there are vendors shipping
> >> cloud gateway products that also have no local
> >> mounts that have never run into this problem,
> >> so it's not an issue in actual customer deployments.
> > FYI. I have a patch that fixes this issue
> > by removing the mkstemp call and using
> > only Samba VFS calls.
> I can test it on ceph if you want to send it to me. One of the
> patches I posted earlier fixes a minor bug in the ctemp test that
> allows smbtorture to continue with the other tests after ctemp has
Yeah I noticed that, I'm planning to add that fix
More information about the samba-technical