Hi,
I noticed that I also need to hook the cifs_readdir() path.
Can someone tell me how I can construct the file name
relative to the mount point. The TODO in this change.
--- a/fs/cifs/readdir.c
+++ b/fs/cifs/readdir.c
@@ -679,7 +679,7 @@ static int cifs_get_name_from_search_buf(struct qstr
*pqst,
return rc;
}
-static int cifs_filldir(char *pfindEntry, struct file *file, filldir_t
filldir,
+static int cifs_filldir(int xid, char *pfindEntry, struct file *file,
filldir_t filldir,
void *direntry, char *scratch_buf, unsigned int
max_len)
{
int rc = 0;
@@ -731,6 +731,15 @@ static int cifs_filldir(char *pfindEntry, struct
file *file, filldir_t filldir,
cifs_dir_info_to_fattr(&fattr, (FILE_DIRECTORY_INFO *)
pfindEntry, cifs_sb);
+ if (cifs_sb->mnt_cifs_flags & CIFS_MOUNT_MF_SYMLINKS) {
+ int tmprc;
+ const char *full_path = qstring.name;
+ /* TODO: build full path relative to the mount point */
+ tmprc = CIFSCheckMFSymlink(&fattr, full_path, cifs_sb, xid);
+ if (tmprc)
+ cFYI(1, "CIFSCheckMFSymlink: %d", tmprc);
+ }
+
if (inum && (cifs_sb->mnt_cifs_flags & CIFS_MOUNT_SERVER_INUM)) {
fattr.cf_uniqueid = inum;
} else {
@@ -856,7 +865,7 @@ int cifs_readdir(struct file *file, void *direntry,
filldir_t filldir)
}
/* if buggy server returns . and .. late do
we want to check for that here? */
- rc = cifs_filldir(current_entry, file,
+ rc = cifs_filldir(xid, current_entry, file,
filldir, direntry, tmp_buf,
max_len);
if (rc == -EOVERFLOW) {
rc = 0;
metze
Am 05.08.2010 14:31, schrieb Jeff Layton:
> On Thu, 05 Aug 2010 17:40:36 +0530
> Suresh Jayaraman <sjayaraman@xxxxxxx> wrote:
>
>> On 08/04/2010 08:07 PM, Jeff Layton wrote:
>>> On Wed, 4 Aug 2010 16:11:44 +0200
>>> Stefan Metzmacher <metze@xxxxxxxxx> wrote:
>>>
>>>> Signed-off-by: Stefan Metzmacher <metze@xxxxxxxxx>
>>>> ---
>>>> fs/cifs/cifsproto.h | 3 +++
>>>> fs/cifs/inode.c | 7 +++++++
>>>> fs/cifs/link.c | 8 ++++++++
>>>> 3 files changed, 18 insertions(+), 0 deletions(-)
>>>>
>>>> diff --git a/fs/cifs/cifsproto.h b/fs/cifs/cifsproto.h
>>>> index 2eaebbd..e94e095 100644
>>>> --- a/fs/cifs/cifsproto.h
>>>> +++ b/fs/cifs/cifsproto.h
>>>> @@ -409,4 +409,7 @@ extern int CIFSSMBSetPosixACL(const int xid, struct cifsTconInfo *tcon,
>>>> extern int CIFSGetExtAttr(const int xid, struct cifsTconInfo *tcon,
>>>> const int netfid, __u64 *pExtAttrBits, __u64 *pMask);
>>>> extern void cifs_autodisable_serverino(struct cifs_sb_info *cifs_sb);
>>>> +extern int CIFSCheckMFSymlink(struct cifs_fattr *fattr,
>>>> + const unsigned char *path,
>>>> + struct cifs_sb_info *cifs_sb, int xid);
>>>> #endif /* _CIFSPROTO_H */
>>>> diff --git a/fs/cifs/inode.c b/fs/cifs/inode.c
>>>> index a15b3a9..c4121de 100644
>>>> --- a/fs/cifs/inode.c
>>>> +++ b/fs/cifs/inode.c
>>>> @@ -661,6 +661,13 @@ int cifs_get_inode_info(struct inode **pinode,
>>>> if (cifs_sb->mnt_cifs_flags & CIFS_MOUNT_UNX_EMUL)
>>>> cifs_sfu_mode(&fattr, full_path, cifs_sb, xid);
>>>>
>>>> + /* query for SFU type info if supported and needed */
>>>> + if (cifs_sb->mnt_cifs_flags & CIFS_MOUNT_MF_SYMLINKS) {
>>>> + tmprc = CIFSCheckMFSymlink(&fattr, full_path, cifs_sb, xid);
>>>> + if (tmprc)
>>>> + cFYI(1, "CIFSCheckMFSymlink: %d", tmprc);
>>>> + }
>>>> +
>>>
>>> ^^^^^^^^^^^^^^
>>>
>>> This only seems to touch the codepath without posix extensions. What
>>> about when unix extensions are enabled? The previous patch seems to
>>> indicate that the behavior is that mfsymlinks are always used when that
>>> mount option is used even if unix extensions are enabled. If so, then I
>>> think you'll need a similar change in cifs_get_inode_info_unix.
>>>
>>
>> I initially thought so. But, looking again - there is no point in
>> querying for SFU type info if unix extensions are enabled..?
>>
>> Thanks,
>>
>
> I'm not sure that addresses the concern. It's very confusing, but:
>
> SFU != POSIX extensions
>
> The SFU codepath goes through the "normal" cifs code
> (cifs_get_inode_info). The POSIX extensions codepath goes through a
> different codepath (cifs_get_inode_info_unix). Yes, all of this is
> sorely in need of being cleaned up, but that's the way it works today...
>
> Metze's patches seem to indicate that mfsymlinks and unix extensions
> aren't mutually exclusive. The unix codepaths that determine inode
> type and fill out inode data should be using the mfsymlink stuff too.
>
Attachment:
signature.asc
Description: OpenPGP digital signature
