David Holland wrote:
> > It is much more code, since it happens on the client, which sends
> > filesystem operations to lower layers and regain control later using
> > callbacks. Have a look to the sources (xlator/cluster/dht/dht-rename.c)
> > and you will see why it is complex.
>
> Where do
On Tue, Aug 02, 2011 at 04:34:12PM +, Emmanuel Dreyfus wrote:
> > As opposed to link/unlink? I still don't see why this would be more
> > than a half-dozen lines of code, if that. By your previous
> > descriptions it already needs to stat the object to check if it's a
> > directory.
>
>
On Tue, Aug 02, 2011 at 04:30:15PM +, David Holland wrote:
> As opposed to link/unlink? I still don't see why this would be more
> than a half-dozen lines of code, if that. By your previous
> descriptions it already needs to stat the object to check if it's a
> directory.
It is much more code,
On Tue, Aug 02, 2011 at 08:52:56AM +, Emmanuel Dreyfus wrote:
> > Sure. But what does it actually do, such that if you have a symlink it
> > doesn't work to copy the symlink instead of hardlink it?
>
> That would probably work for symlinks, since they cannot be updated.
> But this would r
On Tue, Aug 02, 2011 at 05:45:56PM +0200, Rhialto wrote:
> Ok, then we also want openat(2), fchmodat(2) (which seems to be misnamed
> and looks more like a chmodat(2)), unlinkat(2), fchownat(2) (same remark
> as fchmodat), etc.
And you forgot fexecve(). I agree we want all of them, but I do not th
On Tue 02 Aug 2011 at 09:05:27 +, Emmanuel Dreyfus wrote:
> On Tue, Aug 02, 2011 at 10:02:39AM +0100, Roland C. Dowdeswell wrote:
> > It looks like linkat(2) is POSIX.1-2008 and is implemented by Linux
> > as well as FreeBSD. It might be the more portable direction to go.
>
> Right, then ever
On Tue, Aug 02, 2011 at 10:02:39AM +0100, Roland C. Dowdeswell wrote:
> It looks like linkat(2) is POSIX.1-2008 and is implemented by Linux
> as well as FreeBSD. It might be the more portable direction to go.
Right, then everything is simple, this is just the matter of
implementing a standard sy
On Tue, Aug 02, 2011 at 08:52:56AM +, Emmanuel Dreyfus wrote:
>
> On Mon, Aug 01, 2011 at 07:20:30PM +, David Holland wrote:
> > Sure. But what does it actually do, such that if you have a symlink it
> > doesn't work to copy the symlink instead of hardlink it?
>
> That would probably work
On Mon, Aug 01, 2011 at 07:20:30PM +, David Holland wrote:
> Sure. But what does it actually do, such that if you have a symlink it
> doesn't work to copy the symlink instead of hardlink it?
That would probably work for symlinks, since they cannot be updated.
But this would requires heavy chan
On Mon, Aug 01, 2011 at 09:00:36PM +, David Holland wrote:
> > Not withstanding dh's comment, why not pass in all the namei flags.
> >
> > > + error = namei_simple_user(path, flags, &vp);
>
> Because I gimmicked up the flags for namei_simple specifically to
> disallow that sort
On Mon, Aug 01, 2011 at 09:31:11PM +0100, David Laight wrote:
> > + if (flags & FOLLOW)
> > + namei_simple_flags = NSM_FOLLOW_TRYEMULROOT;
> > + else
> > + namei_simple_flags = NSM_NOFOLLOW_TRYEMULROOT;
> > +
> > + error = namei_simple_user(path, namei_simple_flags, &vp)
On Mon, Aug 01, 2011 at 09:46:33AM +, Emmanuel Dreyfus wrote:
> + if (flags & FOLLOW)
> + namei_simple_flags = NSM_FOLLOW_TRYEMULROOT;
> + else
> + namei_simple_flags = NSM_NOFOLLOW_TRYEMULROOT;
> +
> + error = namei_simple_user(path, namei_simple_flags, &vp
Christos Zoulas wrote:
> Except for the ktruser() call, looks good to me (my personal opinion).
Um, yes, that one was another pending patch I had for later. For now
ktrace does not show symlink(2) targets, which is annoying: sometime
you cannot tell what is going on.
--
Emmanuel Dreyfus
http:
On Mon, Aug 01, 2011 at 04:05:32AM +0200, Emmanuel Dreyfus wrote:
> > You still haven't explained what glusterfs is doing that's so evil or
> > why it can't be fixed by having it copy the symlink when that's the
> > case in question.
>
> glusterfs uses the native filesystem as its storage bac
On Mon, Aug 01, 2011 at 09:46:33AM +, Emmanuel Dreyfus wrote:
> +return do_sys_link(l, path, link, FOLLOW, retval);
>
> +return do_sys_link(l, path, link, NOFOLLOW, retval);
Can you use a boolean argument for that instead of namei flags?
> +.Fn llink
> +is like
> +.Fn link
> +
In article <20110801094633.ga17...@homeworld.netbsd.org>,
Emmanuel Dreyfus wrote:
>-=-=-=-=-=-
>
>On Sun, Jul 31, 2011 at 06:36:53PM +, Christos Zoulas wrote:
>> I don't have an issue with it as long as:
>> - fsck does not get confused
>> - filesystems don't need to be modified to s
On Mon 01 Aug 2011 at 12:09:34 +0200, Joerg Sonnenberger wrote:
> You are adding a lot of complexity to workaround portability issues of a
> single application. Let's start the other way -- has FreeBSD added
> llink(2)? What about OSX? Solaris?
FreeBSD 8 has ln -P. From the manual, it seems that t
Rhialto wrote:
> LN(1) FreeBSD General Commands Manual LN(1)
(...)
> -PWhen creating a hard link to a symbolic link, create a hard link to
>the symbolic link itself. This option cancels the -L option.
I can add this this to NetBSD as well
On Mon 01 Aug 2011 at 10:50:50 +0200, Matthias Drochner wrote:
> While the "DESCRIPTION" chapter doesn't tell it explicitely,
> we have the following in "ERRORS":
>
> [ELOOP]
> A loop exists in symbolic links encountered during resolution of the path1
> or path2 argument.
>
> This implies that
Joerg Sonnenberger wrote:
> > You did not explain what problems it would introduce, did you?
> You are adding a lot of complexity to workaround portability issues of a
> single application.
It is not that complex. See the patch I posted this morning, the thing
is really simple, and it works qui
On Mon, Aug 01, 2011 at 04:05:33AM +0200, Emmanuel Dreyfus wrote:
> Joerg Sonnenberger wrote:
>
> > Given the very small number of programs that manage to mess up the
> > symlink usage, I'm kind of opposed to providing another system call just
> > as work around for them.
>
> You did not explain
On Sun, Jul 31, 2011 at 06:36:53PM +, Christos Zoulas wrote:
> I don't have an issue with it as long as:
> - fsck does not get confused
> - filesystems don't need to be modified to support it
> - there is consensus that this is not harmful
> - I am also ambivalent about
m...@netbsd.org said:
> Both behaviors are standard compliant, since SUSv2 says nothing about
> resolving symlinks or not.
While the "DESCRIPTION" chapter doesn't tell it explicitely,
we have the following in "ERRORS":
[ELOOP]
A loop exists in symbolic links encountered during resolution of the
In article <20110731224944.ga23...@britannica.bec.de>,
Joerg Sonnenberger wrote:
>On Sun, Jul 31, 2011 at 07:49:20PM +0200, Emmanuel Dreyfus wrote:
>> Both behaviors are standard compliant, since SUSv2 says nothing about
>> resolving symlinks or not. I found at least one program (glusterfs),
>> w
Joerg Sonnenberger wrote:
> Given the very small number of programs that manage to mess up the
> symlink usage, I'm kind of opposed to providing another system call just
> as work around for them.
You did not explain what problems it would introduce, did you?
--
Emmanuel Dreyfus
http://hcpnet.
David Holland wrote:
> You still haven't explained what glusterfs is doing that's so evil or
> why it can't be fixed by having it copy the symlink when that's the
> case in question.
glusterfs uses the native filesystem as its storage backend. When you
rename a filesytem object in the distribute
On Sun, Jul 31, 2011 at 07:49:20PM +0200, Emmanuel Dreyfus wrote:
> Quick summary for the impatient: NetBSD link(2) first resolves symlinks
> before doing the actual link to the target. As a result, NetBSD link(2)
> fails on symlinks to directories or to non existent targets.
>
> On the other
On Sun, Jul 31, 2011 at 07:49:20PM +0200, Emmanuel Dreyfus wrote:
> Both behaviors are standard compliant, since SUSv2 says nothing about
> resolving symlinks or not. I found at least one program (glusterfs),
> which assumes the Linux behavior, and is a real pain to fix on NetBSD
> because of that.
On Sun, Jul 31, 2011 at 06:36:53PM +, Christos Zoulas wrote:
>
> Also perhaps just call it link2(from, to, flags) in the long tradition
> of adding a number to existing syscalls when extending them ;-)
Or perhaps llink(2) for symmetry with lchmod(2) and lstat(2).
--
Roland Dowdeswell
On Jul 31, 9:18pm, el...@imrryr.org ("Roland C. Dowdeswell") wrote:
-- Subject: Re: Adding linux_link(2) system call, second round
| On Sun, Jul 31, 2011 at 06:36:53PM +, Christos Zoulas wrote:
| >
|
| > Also perhaps just call it link2(from, to, flags) in the long tradition
In article <1k5abxi.a8h289rm4jc3m%m...@netbsd.org>,
Emmanuel Dreyfus wrote:
>Quick summary for the impatient: NetBSD link(2) first resolves symlinks
>before doing the actual link to the target. As a result, NetBSD link(2)
>fails on symlinks to directories or to non existent targets.
>
>On the othe
Quick summary for the impatient: NetBSD link(2) first resolves symlinks
before doing the actual link to the target. As a result, NetBSD link(2)
fails on symlinks to directories or to non existent targets.
On the other side, Linux link(2) is dumb and just create a second
symlink with the same inode
32 matches
Mail list logo
