I've never used DFS so I'm not sure what u mean by having to reply with a redirect of "\server\share\home/userluser/eLItE\haXor/". Do u mean it has to have a way of interpreting that string or that it should send a redirect to the client saying "u really want this path...". I think there's a few ways to resolve the ambiguity. First is to explicitly set the path seperator. Second would be to infer the path seperator from the first char after the share name. A backslash in the above example. A third option would be to retain mixed seperators and require a double backslash escape of literal backslashes. My preference would be to require all backslashes as the sole path seperator and escape literal backslashes like we escape them everywhere else. A left field possibility would be to require paths to be passed to the server as struct's of some kind. That would obviate the problem.
-----Original Message----- From: Jeremy Allison [mailto:[EMAIL PROTECTED] Sent: Fri 3/9/07 3:54 PM To: Wagner, Chris (GE Infra, Non-GE, US) Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [linux-cifs-client] POSIX pathnames and the '\' character. The problem for me is in POSIX pathname processing (when both server and client support the UNIX extensions). Currently the client would send a pathname of : "/home/userluser/eLItE\haXor/" and the smbd server would interpret it as : "/home/userluser/eLItE/haXor/" which is incorrect. Now that's easy to fix, but the problem is when the client is in unix extensions posix pathname mode and accesses a DFS share which needs to reply with a redirect of : "\server\share\home/userluser/eLItE\haXor/" Jeremy. _______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
