Skip to content

GitLab

Switch branch/tag
  1. 05 Jan, 2009 1 commit
    • Al Viro's avatar
      inode->i_op is never NULL · acfa4380
      Al Viro authored 
      
We used to have rather schizophrenic set of checks for NULL ->i_op even
though it had been eliminated years ago.  You'd need to go out of your
way to set it to NULL explicitly _and_ a bunch of code would die on
such inodes anyway.  After killing two remaining places that still
did that bogosity, all that crap can go away.
Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      acfa4380
  3. 26 Dec, 2008 1 commit
  5. 13 Nov, 2008 1 commit
  7. 03 Nov, 2008 1 commit
  9. 23 Oct, 2008 1 commit
  11. 20 Oct, 2008 4 commits
  13. 17 Oct, 2008 1 commit
  15. 07 Oct, 2008 1 commit
    • Steve French's avatar
      [CIFS] clean up error handling in cifs_unlink · 6050247d
      Steve French authored 
      
Currently, if a standard delete fails and we end up getting -EACCES
we try to clear ATTR_READONLY and try the delete again. If that
then fails with -ETXTBSY then we try a rename_pending_delete. We
aren't handling other errors appropriately though.

Another client could have deleted the file in the meantime and
we get back -ENOENT, for instance. In that case we wouldn't do a
d_drop. Instead of retrying in a separate call, simply goto the
original call and use the error handling from that.

Also, we weren't properly undoing any attribute changes that
were done before returning an error back to the caller.

CC: Jeff Layton <jlayton@redhat.com>
Signed-off-by: default avatarSteve French <sfrench@us.ibm.com>
      6050247d
  17. 06 Oct, 2008 1 commit
  19. 24 Sep, 2008 3 commits
  21. 23 Sep, 2008 3 commits
    • Steve French's avatar
      [CIFS] fix busy-file renames and refactor cifs_rename logic · ee2fd967
      Steve French authored 
      
Break out the code that does the actual renaming into a separate
function and have cifs_rename call that. That function will attempt a
path based rename first and then do a filehandle based one if it looks
like the source is busy.

The existing logic tried a path based rename first, but if we needed to
remove the destination then it only attempted a filehandle based rename
afterward. Not all servers support renaming by filehandle, so we need to
always attempt path rename first and fall back to filehandle rename if
it doesn't work.

This also fixes renames of open files on windows servers (at least when
the source and destination directories are the same).

CC: Jeff Layton <jlayton@redhat.com>
Signed-off-by: default avatarSteve French <sfrench@us.ibm.com>
      ee2fd967
    • Jeff Layton's avatar
      cifs: add function to set file disposition · 6d22f098
      Jeff Layton authored 
      
cifs: add function to set file disposition

The proper way to set the delete on close bit on an already existing
file is to use SET_FILE_INFO with an infolevel of
SMB_FILE_DISPOSITION_INFO. Add a function to do that and have the
silly-rename code use it.
Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
Signed-off-by: default avatarSteve French <sfrench@us.ibm.com>
      6d22f098
    • Jeff Layton's avatar
      cifs: move rename and delete-on-close logic into helper function · a12a1ac7
      Jeff Layton authored 
      
cifs: move rename and delete-on-close logic into helper function

When a file is still open on the server, we attempt to set the
DELETE_ON_CLOSE bit and rename it to a new filename. When the
last opener closes the file, the server should delete it.

This patch moves this mechanism into a helper function and has
the two places in cifs_unlink that do this procedure call it. It
also fixes the open flags to be correct.
Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
Signed-off-by: default avatarSteve French <sfrench@us.ibm.com>
      a12a1ac7
  23. 16 Sep, 2008 2 commits
  25. 19 Aug, 2008 1 commit
  27. 14 Aug, 2008 1 commit
    • Steve French's avatar
      [CIFS] mount of IPC$ breaks with iget patch · ad661334
      Steve French authored 
      
In looking at network named pipe support on cifs, I noticed that
Dave Howell's iget patch:

    iget: stop CIFS from using iget() and read_inode()

broke mounts to IPC$ (the interprocess communication share), and don't
handle the error case (when getting info on the root inode fails).

Thanks to Gunter who noted a typo in a debug line in the original
version of this patch.

CC: David Howells <dhowells@redhat.com>
CC: Gunter Kukkukk <linux@kukkukk.com>
CC: Stable Kernel <stable@kernel.org>
Signed-off-by: default avatarSteve French <sfrench@us.ibm.com>
      ad661334
  29. 06 Aug, 2008 7 commits
  31. 05 Aug, 2008 1 commit
  33. 23 Jul, 2008 1 commit
  35. 12 Jul, 2008 1 commit
  37. 25 May, 2008 1 commit
    • Jeff Layton's avatar
      disable most mode changes on non-unix/non-cifsacl mounts · 5132861a
      Jeff Layton authored 
      
CIFS currently allows you to change the mode of an inode on a share that
doesn't have unix extensions enabled, and isn't using cifsacl. The inode
in this case *only* has its mode changed in memory on the client. This
is problematic since it can change any time the inode is purged from the
cache.

This patch makes cifs_setattr silently ignore most mode changes when
unix extensions and cifsacl support are not enabled, and when the share
is not mounted with the "dynperm" option. The exceptions are:

When a mode change would remove all write access to an inode we turn on
the ATTR_READONLY bit on the server and remove all write bits from the
inode's mode in memory.

When a mode change would add a write bit to an inode that previously had
them all turned off, it turns off the ATTR_READONLY bit on the server,
and resets the mode back to what it would normally be (generally, the
file_mode or dir_mode of the share).
Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
Signed-off-by: default avatarSteve French <sfrench@us.ibm.com>
      5132861a
  39. 23 May, 2008 4 commits
    • Jeff Layton's avatar
      silently ignore ownership changes unless unix extensions are enabled or we're faking uid changes · 4ca691a8
      Jeff Layton authored 
      
CIFS currently allows you to change the ownership of a file, but unless
unix extensions are enabled this change is not passed off to the server.

Have CIFS silently ignore ownership changes that can't be persistently
stored on the server unless the "setuids" option is explicitly
specified.

We could return an error here (-EOPNOTSUPP or something), but this is
how most disk-based windows filesystems on behave on Linux (e.g.  VFAT,
NTFS, etc). With cifsacl support and proper Windows to Unix idmapping
support, we may be able to do this more properly in the future.
Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
Signed-off-by: default avatarSteve French <sfrench@us.ibm.com>
      4ca691a8
    • Steve French's avatar
      [CIFS] remove trailing whitespace · 4e94a105
      Steve French authored 
      Signed-off-by: default avatarSteve French <sfrench@us.ibm.com>
      4e94a105
    • Jeff Layton's avatar
      when creating new inodes, use file_mode/dir_mode exclusively on mount without unix extensions · b0fd30d3
      Jeff Layton authored 
      
When CIFS creates a new inode on a mount without unix extensions, it
temporarily assigns the mode that was passed to it in the create/mkdir
call. Eventually, when the inode is revalidated, it changes to have the
file_mode or dir_mode for the mount. This is confusing to users who
expect that the mode shouldn't change this way. It's also problematic
since only the mode is treated this way, not the uid or gid. Suppose you
have a CIFS mount that's mounted with:

uid=0,gid=0,file_mode=0666,dir_mode=0777

...if an unprivileged user comes along and does this on the mount:

mkdir -m 0700 foo
touch foo/bar

...there is a period of time where the touch will fail, since the dir
will initially be owned by root and have mode 0700. If the user waits
long enough, then "foo" will be revalidated and will get the correct
dir_mode permissions.

This patch changes cifs_mkdir and cifs_create to not overwrite the
mode found by the initial cifs_get_inode_info call after the inode is
created on the server. Legacy behavior can be reenabled with the
new "dynperm" mount option.
Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
Signed-off-by: default avatarSteve French <sfrench@us.ibm.com>
      b0fd30d3
    • Jeff Layton's avatar
      on non-posix shares, clear write bits in mode when ATTR_READONLY is set · 4468eb3f
      Jeff Layton authored 
      
When mounting a share with posix extensions disabled,
cifs_get_inode_info turns off all the write bits in the mode for regular
files if ATTR_READONLY is set. Directories and other inode types,
however, can also have ATTR_READONLY set, but the mode gives no
indication of this.

This patch makes this apply to other inode types besides regular files.
It also cleans up how modes are set in cifs_get_inode_info for both the
"normal" and "dynperm" cases.
Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
Signed-off-by: default avatarSteve French <sfrench@us.ibm.com>
      4468eb3f
  41. 22 May, 2008 1 commit
  43. 21 May, 2008 1 commit
  45. 20 May, 2008 1 commit
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7