Sergey Bugaev, le mar. 27 avril 2021 11:57:03 +0300, a ecrit:
> lib.c:154:3: warning: ‘strncpy’ specified bound depends on the length
> of the source argument [-Wstringop-overflow=]
> It is my understanding, based on
> https://gcc.gnu.org/bugzilla//show_bug.cgi?id=88059, that GCC does not
> do any
> On 2021-04-27 11:57:03 +0300, Sergey Bugaev wrote:
> On Mon, Apr 26, 2021 at 11:10 PM Samuel Thibault wrote:
>> Err, but wouldn’t the compiler be able to determine that the size was
>> properly computed, and avoid emitting a false-positive warning?
> It is my understanding, based on
On Mon, Apr 26, 2021 at 11:10 PM Samuel Thibault
wrote:
> Err, but wouldn't the compiler be able to determine that the size was
> properly computed, and avoid emitting a false-positive warning?
It is my understanding, based on
https://gcc.gnu.org/bugzilla//show_bug.cgi?id=88059, that GCC does not
Sergey Bugaev, le lun. 26 avril 2021 22:34:45 +0300, a ecrit:
> On Mon, Apr 26, 2021 at 9:02 PM Jessica Clarke wrote:
> > > - strncpy (filepath, path, length);
> > > - strncat (filepath, filename, strlen (filename));
> > > + strcpy (filepath, path);
> > > + strcat (filepath, filename);
> >
> >
s an excuse to try out the "scissors" feature):
-- >8 --
Subject: [PATCH unionfs v2 3/3] Properly null-terminate a string
---
stow.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/stow.c b/stow.c
index 812d33b..ddbcf20 100644
--- a/stow.c
+++ b/stow.c
@@ -2
Sergey Bugaev, le lun. 26 avril 2021 20:08:18 +0300, a ecrit:
> This fixes a build error.
Applied, thanks!
> ---
> stow-mutations.h | 1 +
> stow-priv.h | 4
> stow.c | 9 +
> 3 files changed, 14 insertions(+)
>
> diff --git a/stow-mutations.h b/stow-mutations.h
> in
Jessica Clarke, le lun. 26 avril 2021 19:02:54 +0100, a ecrit:
> On 26 Apr 2021, at 18:08, Sergey Bugaev wrote:
> > This fixes Wstringop-overflow and Wstringop-truncation GCC warnings.
> > See https://gcc.gnu.org/bugzilla//show_bug.cgi?id=88059
> >
> > Also, fix a bug where a string was not prope
; /* node management. */
>
> +#include
> #include
> #include
> #include
> diff --git a/stow.c b/stow.c
> index a04ffdf..812d33b 100644
> --- a/stow.c
> +++ b/stow.c
> @@ -21,7 +21,9 @@
> /* Stow mode for unionfs. */
>
> #include
> +#inc
On 26 Apr 2021, at 18:08, Sergey Bugaev wrote:
>
> This fixes Wstringop-overflow and Wstringop-truncation GCC warnings.
> See https://gcc.gnu.org/bugzilla//show_bug.cgi?id=88059
>
> Also, fix a bug where a string was not properly null-terminated.
> ---
> lib.c | 4 ++--
> stow.c | 5 +++--
> 2 fi
This fixes a build error.
---
stow-mutations.h | 1 +
stow-priv.h | 4
stow.c | 9 +
3 files changed, 14 insertions(+)
diff --git a/stow-mutations.h b/stow-mutations.h
index d36280d..95c1e7f 100644
--- a/stow-mutations.h
+++ b/stow-mutations.h
@@ -21,6 +21,7 @@
/* Onl
Hello,
I'm trying to use unionfs [0]; but I've run into a few build
errors and warnings. With the following patches it builds and
works on the latest Debian GNU/Hurd with GCC 10.
P.S. This is the first time I attempt sending patches over email,
please let me know if I've done anyt
f..812d33b 100644
--- a/stow.c
+++ b/stow.c
@@ -21,7 +21,9 @@
/* Stow mode for unionfs. */
#include
+#include
#include
+#include
#include "ulfs.h"
#include "lib.h"
diff --git a/ulfs.c b/ulfs.c
index 50affa6..773ebc4 100644
--- a/ulfs.c
+++ b/ulfs.c
@@ -19,6 +19,7
This fixes Wstringop-overflow and Wstringop-truncation GCC warnings.
See https://gcc.gnu.org/bugzilla//show_bug.cgi?id=88059
Also, fix a bug where a string was not properly null-terminated.
---
lib.c | 4 ++--
stow.c | 5 +++--
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/lib.c
Justus Winter, le Thu 21 Nov 2013 23:52:24 +0100, a écrit :
> Found using the Clang Static Analyzer.
>
> * pattern.c (patternlist_add): Fix memory leak.
Ack.
> ---
> pattern.c |3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/pattern.c b/pattern.c
> index 409ed23..fd38cf5 100644
>
Found using the Clang Static Analyzer.
* pattern.c (patternlist_add): Fix memory leak.
---
pattern.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/pattern.c b/pattern.c
index 409ed23..fd38cf5 100644
--- a/pattern.c
+++ b/pattern.c
@@ -52,7 +52,10 @@ patternlist_add (struct patternlist
Pino Toscano, le Thu 14 Mar 2013 19:16:14 +0100, a écrit :
> attached there are few patches for unionfs, to port it to pthread and
> fix small build-related issues/warnings.
Applied, thanks!
Samuel
Hi,
attached there are few patches for unionfs, to port it to pthread and
fix small build-related issues/warnings.
Not that unionfs will work any better now that how it did before, but at
least can be compiled again now...
I guess unionfs is covered by the copyright assignment for "
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
matching against package's subdirectories. 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.
> >
>
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
>> > entreat
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 o
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 in
-
> > 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 package's subdirectories. At
> > the time, I was actually in favor of a separate stowfs whi
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 whe
is feature''? Do
> > you refer to pattern matching or to the stowing feature altogether?
>
> Well, I think you're doing a very good job in keeping unionfs useful.
> That's mostly your code (and your translator) now, so you should feel
> free to do everything yo
h more than I do.
> 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 pattern matching or to the stowing feature altogether?
Well, I think you're doing
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
ng against package's subdirectories. 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.
No engineering, just pragmaticism.
Hope this helps getting you in g
-- packaging system.
>
> The idea was that the first level after the stow directory was the
> package, and we were matching against package's subdirectories. At the
> time, I was actually in favor of a separate stowfs which were just
> using common code for unionfs, but politics and oth
t, like: ``Olaf
> Buddenhagen: rather say s.th. like ...''), and put it into the
> unionfs repository. Don't spend too much time on the build
> infrastructure; I'll take care of that as soon as I do the overall
> Automake dance.
Should I go this way, what name f
Hello,
Recently I have been browsing the code implementing the stowing
feature in unionfs it struck me that I cannot figure out the reason
for it to be implemented in the way it is.
Normally the stowing feature works as follows: one starts unionfs in
the following way:
$ settrans -a unionfs
ergiu 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.
> [...]
> > > put it in th
num is
> > checked in an if statement. Is it alright to check this value via an
> > assert in netfs_attempt_sync? Or should I change the handling of the
> > return value in node_init_root instead?
>
> I don't really know the unionfs code, but if these two structure
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 doc
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,
Hello,
To bring the result of reviews of the ``--mount'' patch series
together, I am posting the latest patches in a new subthread. Since
the discussion tree has become sufficiently messy, I'm asking those
who would like to comment to stick with this subthread and reply to
old messages only if it
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 c
o have the mountee started during
initialization of union mount. As I have pointed out in several
E-mails, this is impossible in the simplest case due to a deadlock.
However, PATCH 2/3 moves the mountee startup code in a separate thread
(actually, reuses the update thread existing in unionfs), which
ntee during the
> > initialization of unionfs. The reason is that most translators (at
> > least) try to stat their underlying node, i.e. invoke an RPC on it. If
> > the mountee is started during unionfs initialization phase, it invokes
> > an RPC on the proxy node provided by uni
Hi,
On Thu, Jun 11, 2009 at 08:59:18PM +0300, Sergiu Ivanov wrote:
> This implementation of unionmount implements lazy translator startup,
> because it is impossible to start the mountee during the
> initialization of unionfs. The reason is that most translators (at
> least) try t
Hello,
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. However, according to
http://preview.tinyurl.com/lfy436, I will be able to add this document
to the
n trimming the other parts of unionfs to
the needs of unionmount. The idea is to do as few modifications to
unionfs as it should be necessary to make unionfs capable of hosting
this piece of new functionality. It was concluded that it is best to
add a command line option: ``--mount=MOUNTEE'
ting option to let settrans do all the setup, and have the
> > > translator component only serve as a helper...
> [...]
> > Do you mean that ``settrans --unionmount'' should use unionfs to
> > actually do the union mount?
>
> Perhaps. The ideas are all very va
nly serve as a helper...
[...]
> Do you mean that ``settrans --unionmount'' should use unionfs to
> actually do the union mount?
Perhaps. The ideas are all very vague still.
> If so, what shall the mountee sit on?
Obviously, we need some helper that handles the internal node.
definitely need to
> think about that at some point. I hope Sergiu is taking notes :-)
Do you mean that ``settrans --unionmount'' should use unionfs to
actually do the union mount? If so, what shall the mountee sit on? If
not so, I fail to see any special advantage of this syntax compared to
``settrans unionmount ''.
Regards,
scolobb
PATCH] Update Makefile to make unionfs build.
>
> I wonder, is it useful to include the headers in the message body? Will
> git-am use them, instead of those supplied in the actual main header?...
I included the header because in the example of a commit message
supplied by Thomas
Hi,
On Tue, May 26, 2009 at 11:31:54PM +0300, Sergiu Ivanov wrote:
> -# Hurd unionfs
> -# Copyright (C) 2001, 2002, 2003, 2005 Free Software Foundation, Inc.
> -# Written by Jeroen Dekkers .
> +# Hurd unionmount
> +#
> +# Copyright (C) 2001, 2002, 2003, 2005, 2009 Free S
Hi,
On Wed, May 27, 2009 at 08:48:56PM +0200, Thomas Schwinge wrote:
> In the end, how much code will be shared between unionfs and
> unionmount? Would it perhaps make sense -- in the long term, need not
> be right now -- to transfer the guts of unionfs into a library that
> can th
patch is wrong -- it was able to build before,
if used properly...)
A patch that picks /usr as *default* prefix, if the user hasn't set
anything explicitely, would be fine though.
Also, this is a patch for unionfs itself. It should not go into the
unionmount patch series. (Ideally, it would
Hi,
On Fri, May 29, 2009 at 12:00:30AM +0300, Sergiu Ivanov wrote:
> >From 6f3e628fa4e90ed1316b2919b2d1a7ea08986b4c Mon Sep 17 00:00:00 2001
> From: Sergiu Ivanov
> Date: Thu, 28 May 2009 19:19:23 +0300
> Subject: [PATCH] Update Makefile to make unionfs build.
I wonder, is it us
Hi,
On Tue, May 26, 2009 at 11:31:45PM +0300, Sergiu Ivanov wrote:
> I'm posting a series of patches which bring unionfs to an intermediate
> stage on its road towards unionmount:
A generic remark here: Try to post a patch series as a single thread.
git format-patch has some featur
>From 021667aed570dfb58fe6457685ac8da38e7077a0 Mon Sep 17 00:00:00 2001
From: Sergiu Ivanov
Date: Thu, 28 May 2009 19:27:59 +0300
Subject: [PATCH] Tailor Makefile to produce unionmount executable.
* Makefile: Changed unionfs in target names to unionmount.
Updated the comments.
---
Makef
>From 6f3e628fa4e90ed1316b2919b2d1a7ea08986b4c Mon Sep 17 00:00:00 2001
From: Sergiu Ivanov
Date: Thu, 28 May 2009 19:19:23 +0300
Subject: [PATCH] Update Makefile to make unionfs build.
* Makefile: Update copyright years.
Set $prefix to /usr.
---
Makefile |6 +-
1 files changed
Hello!
On Tue, May 26, 2009 at 11:31:54PM +0300, Sergiu Ivanov wrote:
> diff --git a/Makefile b/Makefile
> index 3129031..b7e5716 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1,6 +1,9 @@
> -# Hurd unionfs
> -# Copyright (C) 2001, 2002, 2003, 2005 Free Software Foundation,
e GNU Mach build
system for the gory details of how I'm doing this at the moment...) --
which is needed for unionfs: see the Makefile rules where this prefix
variable is used.
But for now, with these two changes I mentioned above, plus a proper
commit message (see again
<http://
Hello!
On Tue, May 26, 2009 at 11:31:45PM +0300, Sergiu Ivanov wrote:
> I am working on unionmount project, which is (at the moment) a branch
> in unionfs git repository
> (http://git.savannah.gnu.org/cgit/hurd/unionfs.git/). The goal of
> unionmount is to mount a translator is suc
diff --git a/Makefile b/Makefile
index 3129031..b7e5716 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,9 @@
-# Hurd unionfs
-# Copyright (C) 2001, 2002, 2003, 2005 Free Software Foundation, Inc.
-# Written by Jeroen Dekkers .
+# Hurd unionmount
+#
+# Copyright (C) 2001, 2002, 2003, 2005, 2009
diff --git a/Makefile b/Makefile
index b180072..3129031 100644
--- a/Makefile
+++ b/Makefile
@@ -17,6 +17,9 @@
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
# USA.
+# Get the information from under /usr.
+prefix = /usr/
+
CPP = gcc -E -x c
MIGCOM = mig -cc cat - /dev/nu
Hello,
I am working on unionmount project, which is (at the moment) a branch
in unionfs git repository
(http://git.savannah.gnu.org/cgit/hurd/unionfs.git/). The goal of
unionmount is to mount a translator is such a way that the underlying
filesystem gets merged with the (virtual) filesystem
Hello,
On Thu, May 21, 2009 at 7:55 PM, wrote:
> On Sun, May 17, 2009 at 11:21:42PM +0300, Sergiu Ivanov wrote:
>> On Sat, May 16, 2009 at 11:45 PM, wrote:
>> > On Fri, May 15, 2009 at 10:56:04PM +0300, Sergiu Ivanov wrote:
>
>> > The idea was to create new br
Hi,
On Sun, May 17, 2009 at 11:21:42PM +0300, Sergiu Ivanov wrote:
> On Sat, May 16, 2009 at 11:45 PM, wrote:
> > On Fri, May 15, 2009 at 10:56:04PM +0300, Sergiu Ivanov wrote:
> > The idea was to create new branches in the existing unionfs
> > repository, rather
> Savannah repository?
>>
>> Oh, I was thinking of that, but I don't really have Savannah
>> experience. I have a Savannah account, is that enough to create this
>> new repository?..
>
> The idea was to create new branches in the existing unionfs repository,
>
on't really have Savannah
> experience. I have a Savannah account, is that enough to create this
> new repository?..
The idea was to create new branches in the existing unionfs repository,
rather than creating another repository.
Also note that you needn't bother about that until
nd.
>> I beg my pardon for a bit of a silly question: if I want to fork
>> unionfs from this repository, should I use git clone, git checkout or
>> git fetch to get the source files from the repository you
>> created?.. And, unfourtunately, I'm rather at a loss
onger hold off with pushing changes into this
particular repository. However, this doesn't mean that it's also true
for the other Hurd repositories (which I might still decide to
re-convert).
> I beg my pardon for a bit of a silly question: if I want to fork
> unionfs from this repos
Hello,
On Tue, Apr 28, 2009 at 1:42 AM, Thomas Schwinge wrote:
> <http://git.savannah.gnu.org/cgit/hurd/unionfs.git/> -- but please do not yet
> push changes there.
I beg my pardon for a bit of a silly question: if I want to fork
unionfs from this repository, should I use gi
and their branches have already been published,
>> by the way -- I'm hereby offering to do the conversion for you. Stay
>> tuned.
>
> <http://git.savannah.gnu.org/cgit/hurd/unionfs.git/> -- but please do not yet
> push changes there.
Thank you very much :-) I do not
Hello!
On Thu, Apr 23, 2009 at 09:49:01AM +0200, I wrote:
> So, I'd rather go for the conversion method, to not hide the previous
> history. And, as I'm already in this dirty business -- a bunch of the
> main Hurd's repositories and their branches have already been published,
> by the way -- I'm
Hello,
writes:
> On Wed, Apr 22, 2009 at 02:05:44PM +0300, Sergiu Ivanov wrote:
>
>> I'm going to start implementing the VFS-style union mount
>> functionality (http://preview.tinyurl.com/cpftg2). The current
>> strategy is based on forking off the unionfs code
Hi,
On Wed, Apr 22, 2009 at 02:05:44PM +0300, Sergiu Ivanov wrote:
> I'm going to start implementing the VFS-style union mount
> functionality (http://preview.tinyurl.com/cpftg2). The current
> strategy is based on forking off the unionfs code base (retrieved from
> http
for such flattering appreciation! :-) I'll strive
hard to satisfy the expectations to the maximal degree :-)
>> The current strategy is based on
>> forking off the unionfs code base (retrieved from
>> http://www.nongnu.org/hurdextras/#unionfs). I am going (rather
&
nt for this summer. As he has, through his
previous work, already proven during the last year that he's capable of
working on Hurd stuff, I have no doubt that it will be a success both for
him and for us. :-)
> The current strategy is based on
> forking off the unionfs code base
Hello,
I'm going to start implementing the VFS-style union mount functionality
(http://preview.tinyurl.com/cpftg2). The current strategy is based on
forking off the unionfs code base (retrieved from
http://www.nongnu.org/hurdextras/#unionfs). I am going (rather
naturally) to use git as th
Hi,
> Date: Wed, 01 Apr 2009 19:11:24 +0200 From: "Michael M. Behman"
>
> I wanted to subscribe to GNU/Hurd in GSOC2009, so I had some questions
> about the "Allow Using unionfs Early at Boot
> <http://www.gnu.org/software/hurd/community/gsoc/project_id
Hello,
for those interested, the unionfs translator in hurdextras CVS at
savannah now has a rude writing support. It actually implements
{rm, mk}dir and file creation and unlinking.
I am sure there are still bugs, so testing is seriously appreciated.
Thanks,
Gianluca
--
It was a type of
[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
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, w
he 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 infinite recursion. If it is not,
the lookup process continues
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 link
I'm not sure wether I understand this paragraph correctly. I was
thinking that the primary reason is quite independent from the
unionfs; the reason is simply that the underlying filesystem cannot
resolve a symlink completely (nor can a translater be started with the
correct ".."
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, tha
Hi,
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.
It would create some problems if unionfs would simply use
file_name_l
) recursively
> call each other, where lnode_uninstall() calls lnode_ref_remove() on
> node->dir, which should be locked; I could not find anything that
> indicates that it will be.
Hmm, I will look into that.
> Also, I find it a bit unfortunate that a simple `ls' triggers this
&
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
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 -lfsh
Hello,
after not doing any work on my former shadowfs implementation
anymore for many months, I started working on a new implementation
(`unionfs') few weeks ago. It is quite uncomplete at the moment and
has not few problems. Compared with my former implementation, this
one uses a compl
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
Moritz Schulte <[EMAIL PROTECTED]> writes:
> just out of curiosity: how should the yet-to-be-written unionfs
> implement copy-on-write for file_chmod()?
>
> unionfs usually gives out ports to the underlying files; when in
> copy-on-write mode, it should give out a port
1 - 100 of 101 matches
Mail list logo
