a few cleanup patches

[Jeremy Allison]

On Fri, Oct 25, 2013 at 01:41:27PM +0200, David Disseldorp wrote:
> On Thu, 24 Oct 2013 12:43:00 -0700
> Jeremy Allison <jra at samba.org> wrote:
> 
> > The old printing code uses it to check driver
> > file versions (it shouldn't) and the completely
> > unused SMB1 file_copy code also seems to use it.
> > Oh yeah, and the get/set file security RPCs
> > used by Win9x clients uses it (again, it shouldn't).
> > 
> > Once I've got some more free time I will eradicate
> > this pest from our code base once and for all :-).
> 
> Sounds great. get_correct_cversion() certainly makes it onto my chopping
> board.
> I hope RENAME_FLAG_COPY falls into the same (unused) category as
> SMBcopy, so the whole code path can be done away with.

Ok, I'm looking at this code path, and I think the
the only case that uses the "special" properties of
INTERNAL_OPEN_ONLY is the dosmode set code, which
gets called with a file path only - even in the middle
of open code processing - and might need to open the
file to get an fsp to call SMB_VFS_FSETXATTR.

Unfortunately, if you look at MS-FSA for setting
attributes, and also at torture/raw/oplock, test
test_raw_oplock_batch25() setting a file attribute
does *not* break any oplock state.

This makes things a little hairy when SMB_VFS_SETXATTR()
on the pathname fails, but as we have write access
to the filename we must become root to allow it.

The only way to fix this is to add SMB_VFS_LSETXATTR()
call into the VFS, cd into the directory first and
then use the last component of the pathname with the
'l' version of the vfs call.

Which leads me back to my original patchset
adding the lXXX VFS calls back into our VFS for 4.2
(phew, a long and circuitous route :-). I'll think
about whether we need to add all of them into the
POSIX VFS API, or if we can get away with just
adding the ones we know we're going to use (like
the lsetxattr - which of course Solaris doesn't
support...).

Jeremy