Age | Commit message (Collapse) | Author | Files | Lines |
|
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)
|