From: Jeremy Allison <jra@samba.org>
To: Igor Mammedov <niallain@gmail.com>
Cc: Jeremy Allison <jra@samba.org>, Steve French <smfrench@gmail.com>,
"Q (Igor Mammedov)" <qwerty0987654321@mail.ru>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
linux-cifs-client@lists.samba.org
Subject: Re: dfs path construction fixup for / character in \\server\share component of dfs path
Date: Fri, 23 May 2008 17:46:06 -0700 [thread overview]
Message-ID: <20080524004605.GB13893@jeremy-laptop> (raw)
In-Reply-To: <48342A5C.9060000@gmail.com>
On Wed, May 21, 2008 at 05:57:48PM +0400, Igor Mammedov wrote:
>
> Magic is really sucks. Because of DFS junction point
> is symlink in samba, when unix ext. is on, we had to do
> that magic thing in the kernel code.
> Now we have following behavior:
> 1. when client makes 'ls' for the first time on the
> directory with DFS links, 'ls' shows them as symlinks.
> 2. when we follow through a such 'symlink', it finely
> becomes a directory.
> That magic!!!
> Of cause it is possible to rewrite such 'symlink' in readdir
> syscall handler, but is it the best way?
>
> IMHO:
> For a client the way better to see a directory from the start.
> (common code for handling this case for MS and Samba servers)
> and no magic at all.
I can easily do this in the server, the problem is
how we define what is "correct" from the client
view with the UNIX extensions turned on.
Because we are overloading the filesystem to
store DFS links as symlinks, it's arguable
which way they should be seen. If a symlink
with the corrcet contents is "magically" seen
as a directory, then a client can write a
symlink which is then no longer seen as a
symlink, but turns into a directory when
queried.
The problem is the Samba implementation
is bleeding out onto the wire here. As we're
stuck with it for the time being we have to
make the best of it. Trouble is, I'm not
sure what exactly the right decision is
here..
Jeremy.
next prev parent reply other threads:[~2008-05-24 0:46 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-18 23:03 dfs path construction fixup for / character in \\server\share component of dfs path Steve French
2008-04-23 14:28 ` Igor Mammedov
2008-04-23 19:11 ` Jeremy Allison
2008-04-23 19:19 ` Jeremy Allison
2008-04-24 8:04 ` Igor Mammedov
2008-04-25 19:22 ` Jeremy Allison
2008-04-25 19:50 ` Jeremy Allison
2008-04-25 21:16 ` Jeremy Allison
2008-04-27 13:00 ` Igor Mammedov
2008-04-28 18:05 ` Jeremy Allison
2008-04-28 18:51 ` Jeremy Allison
2008-05-21 13:57 ` Igor Mammedov
2008-05-24 0:46 ` Jeremy Allison [this message]
2008-05-24 1:33 ` Steve French
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080524004605.GB13893@jeremy-laptop \
--to=jra@samba.org \
--cc=linux-cifs-client@lists.samba.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=niallain@gmail.com \
--cc=qwerty0987654321@mail.ru \
--cc=smfrench@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).