mirror of
https://github.com/samba-team/samba.git
synced 2024-12-23 17:34:34 +03:00
e89fd49df7
socket connections. This was complicated by a few factors:
- it meant moving the event context from clitransport to clisocket,
so lots of structures changed
- we need to asynchronously handle connection to lists of port
numbers, not just one port number. The code internally tries each
port in the list in turn, without ever blocking
- the man page on how connect() is supposed to work asynchronously
doesn't work in practice (now why doesn't this surprise me?). The
getsockopt() for SOL_ERROR is supposed to retrieve the error, but
in fact the next (unrelated) connect() call on the same socket also
gets an error, though not the right error. To work around this I
need to tear down the whole socket between each attempted port. I
hate posix.
Note that clisocket.c still does a blocking name resolution call in
smbcli_sock_connect_byname(). That will be fixed when we add the async
NBT resolution code.
Also note that I arranged things so that every SMB connection is now
async internally, so using plain smbclient or smbtorture tests all the
async features of this new code.
(This used to be commit
|
||
|---|---|---|
| .. | ||
| cifs | ||
| common | ||
| ipc | ||
| nbench | ||
| posix | ||
| simple | ||
| unixuid | ||
| config.mk | ||
| ntvfs_base.c | ||
| ntvfs_generic.c | ||
| ntvfs_interface.c | ||
| ntvfs_util.c | ||
| ntvfs.h | ||
| README | ||
This is the base of the new NTVFS subsystem for Samba. The model for NTVFS backends is quite different than for the older style VFS backends, in particular: - the NTVFS backends receive windows style file names, although they are in the unix charset (usually UTF8). This means the backend is responsible for mapping windows filename conventions to unix filename conventions if necessary - the NTVFS backends are responsible for changing effective UID before calling any OS local filesystem operations (if needed). The become_*() functions are provided to make this easier. - the NTVFS backends are responsible for resolving DFS paths - each NTVFS backend handles either disk, printer or IPC$ shares, rather than one backend handling all types - the entry points of the NTVFS backends correspond closely with basic SMB operations, wheres the old VFS was modelled directly on the POSIX filesystem interface. - the NTVFS backends are responsible for all semantic mappings, such as mapping dos file attributes, ACLs, file ownership and file times