; a=shortlog; h=refs/heads/struct_stat

Volker Lendecke Volker.Lendecke at SerNet.DE
Thu May 14 14:49:04 GMT 2009


Under $SUBJECT find two commits that make SMB_STRUCT_STAT a
structure that we define on our own. From the checkin

Introduce "struct stat_ex" as a replacement for SMB_STRUCT_STAT

This patch introduces

struct stat_ex {
        dev_t           st_ex_dev;
        ino_t           st_ex_ino;
        mode_t          st_ex_mode;
        nlink_t         st_ex_nlink;
        uid_t           st_ex_uid;
        gid_t           st_ex_gid;
        dev_t           st_ex_rdev;
        off_t           st_ex_size;
        struct timespec st_ex_atime;
        struct timespec st_ex_mtime;
        struct timespec st_ex_ctime;
        struct timespec st_ex_btime; /* birthtime */
        blksize_t       st_ex_blksize;
        blkcnt_t        st_ex_blocks;
typedef struct stat_ex SMB_STRUCT_STAT;

It is really large because due to the friendly libc headers
playing macro tricks with fields like st_ino, so I renamed
them to st_ex_xxx.

Why this change? To support birthtime, we already have quite
a few #ifdef's at places where it does not really belong.
With a stat struct that we control, we can consolidate the
nanosecond timestamps and the birthtime deep in the VFS stat

At this moment it is triggered by a request to support the
birthtime field for GPFS. GPFS does not extend the system
level struct stat, but instead has a separate call that gets
us the additional information beyond posix. Without being
able to do that within the VFS stat calls, that support
would have to be scattered around the main smbd code.

It will very likely break all the onefs modules, but I think
the changes will be reasonably easy to do.



P.S: This patch also makes "fake directory create times" a
global option. This IMO is so obscure that it does not
really matter.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url :

More information about the samba-technical mailing list