[linux-cifs-client] Re: undo changes in cifs_rename_pending_delete if it errors out

[Jeff Layton]

On Fri, 17 Oct 2008 12:48:37 -0500
"Steve French" <smfrench at gmail.com> wrote:

> The patch "undo changes in cifs_rename_pending_delete if it errors out"
> http://git.samba.org/?p=jlayton/cifs.git;a=commitdiff;h=efb30e1f42da17280052f42ff4b5be0514742f24
> 
> gives up if you fail the newly added QueryPathInfo of the original
> file.   Won't this unnecessarily fail if e.g. we don't have
> read-attributes but do have write attributes and delete permission?
> We don't have to know the files current attributes (they have been
> read within the last second already so we should know a recent
> version) - so if it fails it is harmless.   Even if we do want to do
> this - would it be safer to do it on the newly opened handle which you
> are about to open?
> 
[...]
> If we do add a QPathInfo(FILE_ALL_INFO) - why do we only use the
> delete pending flag and not the attributes - your patch still takes
> the attributes from the original inode rather than the return from
> QPathInfo

I'm open to suggestion here. If skipping this call altogether is
better, I'm ok with doing that. I'm not certain that windows always
reports the pending delete flag in that attributes however, which was
why I went with this method (much of this was based on my own
experimentation). A better scheme might be to save the DeletePending
state to a new field in the cifsInode, and skip the extra call here.

You're correct though that if we do want to do the QPathInfo call, we
should update the cifsAttrs with the info in it.

-- 
Jeff Layton <jlayton at redhat.com>