| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Office 2003.
Confirmation from reporter that this fixes the issue in master on ext3/ext4.
Back-ports to follow.
Jeremy.
|
|
|
|
|
|
|
|
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 calls.
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.
|
|
Michael
|
|
(This used to be commit 5ccdc58ce91ee40ca7171dd040191291aeb7fe02)
|
|
(This used to be commit 794e48b809036871287df8416a2c669b7e26f216)
|
|
pull.
Jeremy.
(This used to be commit f4a1fdaac0dd6b1b241fac9879416c8ad4403eff)
|
|
Allow to specify value of DMAPI attribute returned during offline file checks, 'tsmsm: dmapi value'.
Previously tsmsm module has supported only IBM TSM SM engine which reports file state by *existence*
of a certain DMAPI attribute. Other HSM systems report a certain value as DMAPI request's result.
Port from Tridge's v3-0-ctdb git tree.
(This used to be commit 1faa97d5cc51277abbc6cb5c37d31c429bea04e4)
|
|
Alexander, please check!
(This used to be commit df574fd2ee58f008b93b06f4d78c85cb909cc92c)
|
|
(This used to be commit 863b5ed07aca0978aeaf919d7c51204a95ce03e0)
|
|
Support cases when existing DMAPI session is stale. In this case we are creating another one.
The code differs from 3-0_ctdb branch in that we fail when it is not possible to create more
sessions and pretend that file is offline. This allows to escape endless loop in vfs_tsmsm.c.
(This used to be commit 5efb57d904e25e68b09a567e260292439ad9c095)
|
|
(This used to be commit cf1f90ad7a79dbe5926018790bb50d4e3b36cc7b)
|
|
handle FS capabilities.
As discussed with Volker, it is better to calculate FS capabilities at
connection time. We already do this with help of VFS statvfs() call
which allows to fill-in system-specific attributes including FS
capabilities. So just re-use it if you want to represent additional
capabilities in your modules. The only caution is that you need to
call underlying statvfs() call to actually get system-specific
capabilities (and other fields) added. Then add module-specific ones.
(This used to be commit e342ca0d931f9a5c8ec9e472dc9c63f1fe012b3a)
|
|
result for a file.
This makes sense as upper levels are only taking returned result of 0
(no error) into consideration when deciding whether to mark file
offline/online as returned from is_offline.
That means that we simply can move the decision down to VFS module and
clean up upper levels so that they always see only file status. If there
is an error when trying to identify file status, then VFS module could
decide what to return (offline or online) by itself -- after all, it
ought to have system-specific knowledge anyway.
(This used to be commit 75cc08661473cce62756fa062071bb2bc1fb39ec)
|
|
I'm sorry for this mess. :-(
(This used to be commit e1f5a8f10795831d3c7902d9803c9571c8ac811a)
|
|
Signed-off-by: Alexander Bokovoy <ab@samba.org>(This used to be commit d7752449f38747d59c93869656a5f7c02ebdf084)
|
