Hello,
On Thu, Oct 29, 2009 at 07:30:41AM +0100, olafbuddenha...@gmx.net wrote:
> On Mon, Aug 17, 2009 at 01:03:30PM +0300, Sergiu Ivanov wrote:
>
> > If one would like to keep *both* the information about the filesystems
> > *and* the ports to their root nodes in *a single* place, one would
> >
Hi,
On Mon, Aug 17, 2009 at 01:03:30PM +0300, Sergiu Ivanov wrote:
> If one would like to keep *both* the information about the filesystems
> *and* the ports to their root nodes in *a single* place, one would
> have two choices: either add something like a ``port'' field to each
> entry in the ul
On Fri, Aug 28, 2009 at 3:22 AM, wrote:
> On Sun, Aug 23, 2009 at 10:42:41PM +0200, Gianluca Guida wrote:
>
>> At the time, I was actually in favor of a separate stowfs which were
>> just using common code for unionfs, but politics and other rather
>> meaningless reasons brought it into the way it
Hello,
On Fri, Aug 28, 2009 at 03:37:23AM +0200, olafbuddenha...@gmx.net wrote:
> On Mon, Aug 24, 2009 at 12:07:18AM +0300, Sergiu Ivanov wrote:
> > On Sun, Aug 23, 2009 at 10:42:41PM +0200, Gianluca Guida wrote:
>
> > > I do agree that it's counter-intuitive. Please note that the stow
> > > func
On Fri, Aug 28, 2009 at 2:37 AM, wrote:
> On Wed, Aug 26, 2009 at 01:07:27AM +0200, Gianluca Guida wrote:
>> > This is a non-trivial problem. Other unionfs implementations
>> > probably spent considerable time figuring out how to do it best. I
>> > entreated Gianluca to check what over implementat
Hi Gianluca,
On Wed, Aug 26, 2009 at 01:07:27AM +0200, Gianluca Guida wrote:
> Hm, funny things happens while grepping past mail.
Hehe... Nice to see you here :-)
> > This is a non-trivial problem. Other unionfs implementations
> > probably spent considerable time figuring out how to do it best
Hi,
On Sun, Aug 23, 2009 at 10:42:41PM +0200, Gianluca Guida wrote:
> At the time, I was actually in favor of a separate stowfs which were
> just using common code for unionfs, but politics and other rather
> meaningless reasons brought it into the way it is now.
Really? That's interesting -- I
Hi,
On Mon, Aug 24, 2009 at 12:07:18AM +0300, Sergiu Ivanov wrote:
> On Sun, Aug 23, 2009 at 10:42:41PM +0200, Gianluca Guida wrote:
> > I do agree that it's counter-intuitive. Please note that the stow
> > functionality was mostly meant for the GNU system as a base for a --
> > rather complex I'
Hi,
On Sun, Aug 23, 2009 at 11:38:26PM +0200, Gianluca Guida wrote:
> On Sun, Aug 23, 2009 at 11:07 PM, Sergiu
> Ivanov wrote:
> > I wonder whether there is still the necessity to keep things as they
> > are. I can see that the files in which you are mentioned as the
> > author date back to 2005
Hm, funny things happens while grepping past mail.
> This is a non-trivial problem. Other unionfs implementations probably
> spent considerable time figuring out how to do it best. I entreated
> Gianluca to check what over implementations do, instead of trying to
> reinvent the wheel -- but he wou
Hello,
On Mon, Aug 24, 2009 at 12:23:38PM +0100, Gianluca Guida wrote:
> On Mon, Aug 24, 2009 at 9:20 AM, Sergiu
> Ivanov wrote:
>
> > I'm glad you feel okay about my suggestion :-) However, I'm not sure I
> > can understand correctly what you mean by ``remove this feature''? Do
> > you refer to
On Mon, Aug 24, 2009 at 9:20 AM, Sergiu
Ivanov wrote:
> Oh, sorry, I should have asked *you* in the first place :-( Please,
> forgive my absent-mindedness :-(
Nah, it's OK. Thomas and antrik are the right guys to ask in general,
since they're following your work and the Hurd much more than I do.
Hello,
On Sun, Aug 23, 2009 at 11:38:26PM +0200, Gianluca Guida wrote:
> On Sun, Aug 23, 2009 at 11:07 PM, Sergiu
> Ivanov wrote:
> > Thomas, antrik, what do you think? Could it be acceptable to give the
> > stow pattern matching feature a more intuitive face?
>
> I am pretty sure they are favor
On Sun, Aug 23, 2009 at 11:07 PM, Sergiu
Ivanov wrote:
> I see... It has never occurred to me that unionfs could be used in a
> packaging system :-)
There are things you don't really want to know about the Hurd. :-)
> I wonder whether there is still the necessity to keep things as they
> are. I
Hi Sergiu,
I do agree that it's counter-intuitive. Please note that the stow
functionality was mostly meant for the GNU system as a base for a --
rather complex I'd say -- packaging system.
The idea was that the first level after the stow directory was the
package, and we were matching against pa
Hello,
Thank you for the swift response!
On Sun, Aug 23, 2009 at 10:42:41PM +0200, Gianluca Guida wrote:
> I do agree that it's counter-intuitive. Please note that the stow
> functionality was mostly meant for the GNU system as a base for a --
> rather complex I'd say -- packaging system.
>
> Th
Hello,
On Tue, Aug 04, 2009 at 01:00:10AM +0200, Thomas Schwinge wrote:
> On Fri, Jul 17, 2009 at 05:08:28AM +0200, olafbuddenha...@gmx.net wrote:
> > On Sat, Jun 13, 2009 at 09:23:23AM +0300, Sergiu Ivanov wrote:
>
> Sergiu, then please remove the shadowfs reference(s) from the GNU
> Hurd Refere
Hello!
On Sun, Aug 16, 2009 at 08:06:28PM +0200, olafbuddenha...@gmx.net wrote:
> On Tue, Aug 04, 2009 at 01:00:10AM +0200, Thomas Schwinge wrote:
> > On Fri, Jul 17, 2009 at 05:08:28AM +0200, olafbuddenha...@gmx.net wrote:
> > > On Sat, Jun 13, 2009 at 09:23:23AM +0300, Sergiu Ivanov wrote:
> > >
Hi,
On Tue, Aug 04, 2009 at 01:00:10AM +0200, Thomas Schwinge wrote:
> On Fri, Jul 17, 2009 at 05:08:28AM +0200, olafbuddenha...@gmx.net wrote:
> > On Sat, Jun 13, 2009 at 09:23:23AM +0300, Sergiu Ivanov wrote:
> > > I'm sending in my attempt to compile a unionfs documentation. It
> > > is format
Hello!
On Fri, Jul 17, 2009 at 05:08:28AM +0200, olafbuddenha...@gmx.net wrote:
> On Sat, Jun 13, 2009 at 09:23:23AM +0300, Sergiu Ivanov wrote:
> > I'm sending in my attempt to compile a unionfs documentation. It is
> > formatted as a stand-alone Texinfo file for now, so that I am able to
> > bui
Hi,
On Sat, Jun 13, 2009 at 09:23:23AM +0300, Sergiu Ivanov wrote:
> I'm sending in my attempt to compile a unionfs documentation. It is
> formatted as a stand-alone Texinfo file for now, so that I am able to
> build and view .info files from it.
I don't understand -- why can't you just build it
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> That's actually not a problem, because each walk through the union
> fs requires a retry. The library is supposed to keep track of how
> many retries it gets, and handle ELOOP itself.
Still, if you imagine many that users create a unionfs based
Moritz Schulte <[EMAIL PROTECTED]> writes:
> After I did the O_NOTRANS lookup in unionfs, I check if the resulting
> node is the same as the one returned by netfs_startup. If it is, I
> return ELOOP to make it impossible to reach the unionfs inside of the
> unionfs again, which would lead to infi
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> What we really want is for the user to do a retry of the name as it
> exists in the "real" location, and then if that results in ENOENT,
> we want the user to return back to the filesystem for another name
> to try.
Well, here you are only consid
Moritz Schulte <[EMAIL PROTECTED]> writes:
> Actually I was not thinking about making ".." go to the unionfs, but
> this surely seems like a good idea.
>
> > If it's a translator (of any kind, including symlink) then it does
> > the translator linkage *itself*, just as diskfs/netfs does it.
>
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> Oh, that. Blech blech blech.
Blech is also corking.
> And, of course, this matters in just this case! Because it's a
> union, and so the node is found in *two* directories and it's not at
> all clear which one is right.
I'm not sure wether I
Moritz Schulte <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
>
> > What exactly would the problem be there? Maybe I've missed a beat
> > in the conversation.
>
> Maybe I am overlooking something, I am not that familiar with
> libdiskfs.
>
> My question is: give
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> What exactly would the problem be there? Maybe I've missed a beat
> in the conversation.
Maybe I am overlooking something, I am not that familiar with
libdiskfs.
My question is: given the situation that dir_lookup is called to
re-open a node, w
Moritz Schulte <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
>
> > I think the right fix is to have lookups for "" do all the normal
> > processing when you open a file.
>
> Well, yes, but the problem of relative symbolic links is not yet
> solved, is it?
What e
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> I think the right fix is to have lookups for "" do all the normal
> processing when you open a file.
Well, yes, but the problem of relative symbolic links is not yet
solved, is it?
moritz
--
[EMAIL PROTECTED] - http://duesseldor
Moritz Schulte <[EMAIL PROTECTED]> writes:
> > It might well be that we have a hole in the interface here. Blech.
>
> So... fs interface change - anyone? =)
I think the right fix is to have lookups for "" do all the normal
processing when you open a file.
That is, it should do the translator s
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> I think that's why I originally stated "." which Roland corrected to
> "".
Well, "." would not work for non-directories, of course.
> It might well be that we have a hole in the interface here. Blech.
So... fs interface change - anyone? =)
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> Instead, you fetch the actual node, and then tell the user to reauth
> *that* node.
Are you sure the needed functionality is implemented?
I tried that, it does not work (with a retry name of ""); the user
keeps the underlying node, he doesn't ge
> Look up the node with O_NOTRANS, and then return *that* to the user,
> with FS_RETRY_REAUTH and a retry name of ".".
Empty string, actually.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
Moritz Schulte <[EMAIL PROTECTED]> writes:
> I was thinking about what unionfs should do with symbolic links and
> translators on the underlying filesystems; i think if unionfs's
> _S_dir_lookup would return retry names in that case, that would be
> reasonable.
Yes, that's right. It needs to d
Wolfgang Jaehrling <[EMAIL PROTECTED]> writes:
> /usr/bin/ld: netfs.o(.debug_info+0x6399): unresolvable relocation
> against symbol `_netfs_translator_callback1'
I am not sure what this is; I don't see it here.
> I noticed that lnode_ref_remove() and lnode_uninstall() recursively
> call each oth
On Sun, Dec 08, 2002 at 09:04:11AM +0100, Moritz Schulte wrote:
> > Also, I find it a bit unfortunate that a simple `ls' triggers this
> > already:
> >
> > wj@hurd:~/unionfs$ settrans -ac foo unionfs .. /
> > wj@hurd:~/unionfs$ ls foo/unionfs/
> > ls: foo/unionfs/foo: Too many levels of symbolic li
On Sat, Dec 07, 2002 at 07:06:09PM +0100, Moritz Schulte wrote:
> Have fun/Happy hacking.
I was just playing around with it a bit and glancing over the code;
when compiling, I got the messages:
gcc -o unionfs main.o node.o lnode.o ulfs.o options.o \
ncache.o netfs.o lib.o -lnetfs -lfshelp -lioh
On Wed, Nov 27, 2002 at 05:16:30PM +0100, Moritz Schulte wrote:
> An example:
>
> I use unionfs on /lib and in /lib there is libfnord.so, which is a
> symbolic link to libfnord.so.42; now /lib/libfnord.so is looked up via
> file_name_lookup_under.
An interesting case is when I have libfnord.s
39 matches
Mail list logo
