All rename paths go through rename_internals_fsp -- low hanging fruit on my quest to add an FSP to VFS functions that deal with files

Richard Sharpe realrichardsharpe at gmail.com
Sat Feb 21 15:34:56 MST 2015


Hi folks,

I am trying to ensure that all VFS functions that deal with files are
passed an FSP.

I noticed that all rename paths go through rename_internals_fsp which
calls SMB_VFS_RENAME.

This means that the rename function can be handed an FSP.

Does anyone object to me making this change while I look at how to add
FSPs to other functions, like:

SMB_VFS_OPENDIR
SMB_VFS_READDIR
SMB_VFS_READDIR_ATTR
SMB_VFS_SEEKDIR
SMB_VFS_TELLDIR
SMB_VFS_REWINDDIR
SMB_VFS_MKDIR
SMB_VFS_RMDIR
SMB_VFS_CLOSEDIR
SMB_VFS_STAT although maybe all should use SMB_VFS_FSTAT
SMB_VFS_LSTAT
SMB_VFS_UNLINK
SMB_VFS_CHMOD although maybe all should use SMB_VFS_FCHMOD
SMB_VFS_CHOWN although maybe all should use SMB_VFS_FCHOWN
SMB_VFS_LCHOWN
SMB_VFS_NTIMES
SMB_VFS_SYMLINK
SMB_VFS_READLINK
SMB_VFS_LINK
SMB_VFS_MKNOD
SMB_VFS_NOTIFY_WATCH
SMB_VFS_GET_REAL_FILENAME?

Actually, it turns out that SMB_VFS_NTIMES is also low-hanging fruit
because it is only called by file_ntimes and in both cases the callers
of this function are passed an fsp! Hmmm, except one of them might be
passed NULL in the fsp!

-- 
Regards,
Richard Sharpe
(何以解憂?唯有杜康。--曹操)


More information about the samba-technical mailing list