2015-02-05 5:26 GMT+01:00 s...@9front.org:
But why we don't have Tmove for example?
http://9front.org/img/tmove.jpg
ROFTL! :-D
2015-02-05 5:13 GMT+01:00 lu...@proxima.alt.za:
But why we don't have Tmove for example?
Because its semantics are much, much more complex and the users need
to be aware of the difference.
This shouldn't be so hard to obtain.
I mean we could simply introduce a new command rename oldpath
Actually I've found a 9 years old mail about Tmove:
http://comp.os.plan9.narkive.com/xYi8Vg5d/9fans-fuse-bashing#post40
I'm not an advocate of Tmove in any way, but I can't really grasp the cons.
I'm sure that its omission was an explicit design choise, but where I
can read about the arguments
I mean we could simply introduce a new command rename oldpath
newpath that only works when both path share the same mount point.
This way the mv commands would keep the old safe semantic, while the
new command would protect the user to accidentally disclosure his data
to the world via the
I'm not an advocate of Tmove in any way, but I can't really grasp the cons.
I'm sure that its omission was an explicit design choise, but where I
can read about the arguments that lead to such decision?
It's a long time ago, but I seem to recall that the clinching argument
hinged around
On Thu, 05 Feb 2015 08:20:30 PST erik quanstrom quans...@quanstro.net wrote:
All this reflections arise from the search for an orthodox way to change
the tree structure of a synthetic filesystem.
Moving large real files is not my actual issue here. I'm wondering for a
synthetic filesystem
option 2 doesn't make sense. using the cpu(1) as a test setup, please show
how such a wstat would work atomically if one does 'mv /mnt/term/foo
/tmp/foo'. note that 'cpu' exports the local fs to the cpu it connects to
(which is then mounted on /mnt/term). also one can 'cpu' to a different
domain
All this reflections arise from the search for an orthodox way to change
the tree structure of a synthetic filesystem.
Moving large real files is not my actual issue here. I'm wondering for a
synthetic filesystem in which, when you move a folder in a special
directory, something magic
Also, in the absence of symbolic links, you don't get to choose
whether to migrate the node or the contents. Things get hairy, not
just complicated.
sorry, we're going to have to disagree on this one. symbolic links are
a huge pain in the butt.
and to address your issue, both find and du
Il 05/Feb/2015 17:26 erik quanstrom quans...@quanstro.net ha scritto:
I'm wondering for a
synthetic filesystem in which, when you move a folder in a special
directory, something magic happens.
As far as I can see, it is not possible with a 9p2000 fileservice, is
it?
i don't see why you
you can consider doing it out of band; e.g. a new fossil console command.
On Wed, Feb 4, 2015 at 6:30 AM Giacomo Tesio giac...@tesio.it wrote:
And unfortunately I cannot figure out any alternative, either. :-(
An interesting point is: why directory entries can be read but cannot be
written? I
2015-02-04 4:51 GMT+01:00 erik quanstrom quans...@quanstro.net:
On Tue Feb 3 01:01:02 PST 2015, st...@quintile.net wrote:
the control file idea is a neat way of doing atomic moves.
control files are a good way of dealing with all kinds of exceptional
behavior.
but ...
to be fair,
you can consider doing it out of band; e.g. a new fossil console command.
On Wed, Feb 4, 2015 at 6:30 AM Giacomo Tesio giac...@tesio.it wrote:
And unfortunately I cannot figure out any alternative, either. :-(
An interesting point is: why directory entries can be read but cannot be
Useless? No I did not mean this.
(and sorry, I wasn't in any way sarcastic, I'm just trying to understand
9p's design a bit deeper)
I mean that to realize a truly uniform interface, directories should be
writable with Twrite, so that we would not need messages like Tcreate and
Tremove (and
You are right.
But since protocol customizations goes against that same ideal, what's the
plan9 way of dealing with a feature X (in this specific case atomic file
moves)?
this requires delving into the namespace to tell that the directories are
still under the
same mount, and some
And unfortunately I cannot figure out any alternative, either. :-(
An interesting point is: why directory entries can be read but cannot be
written? I mean we use Tcreate to create a new file in a dir, while to be
uniform with files, we should use a Twrite, appending a corresponding stat
But why we don't have Tmove for example?
Because its semantics are much, much more complex and the users need
to be aware of the difference. Imagine a Tmove that transfers your
entire disk contents to the cloud: would you like it to be perceived
as trivial? What happens if you interrupt it?
I'm wondering for a
synthetic filesystem in which, when you move a folder in a special
directory, something magic happens.
Magic is overrated.
Lucio.
But why we don't have Tmove for example?
http://9front.org/img/9tmove01.png
sl
On Tue Feb 3 01:01:02 PST 2015, st...@quintile.net wrote:
the control file idea is a neat way of doing atomic moves.
control files are a good way of dealing with all kinds of exceptional behavior.
but ...
to be fair, this goes against the unix ideal of having uniform file operations.
this
Ok, got it.
This annoing thread (sorry) was due to the fact that the only messages that
actually contains the / marker are Tauth and Tattach (in the aname). I
still think that using wstat with such marker to atomically move files
among accessible folders would not violate the protocol
the control file idea is a neat way of doing atomic moves.
this has been discussed before, my summary is its not something you need often
to justify the pain of trying to implement it correctly - the directory locking
has to be done with care to ensure it is all deadlock free.
I do, very
It surely would not be conformant to Plan 9 systems, but to the protocol?
As far as I can read intro(5), it explicitly excludes slash as a valid
character for the Plan 9 OS, but it also explicitly states that the
protocol has no such restriction.
Be patient: I'm asking because this could be a
On Jan 30, 2015, at 10:59 , Giacomo Tesio giac...@tesio.it wrote:
It surely would not be conformant to Plan 9 systems, but to the protocol?
No. Joel has it right. Writing a server which allows / in names would mean that
the / you're slipping into a name wouldn't always be a directory
On Fri, Jan 30, 2015 at 10:59 AM, Giacomo Tesio giac...@tesio.it wrote:
As far as I can read intro(5), it explicitly excludes slash as a valid
character for the Plan 9 OS, but it also explicitly states that the
protocol has no such restriction.
My reading is that a 9p2000 server might allow a
Now, since the protocol does not restrict names (even if Plan 9 does it),
I'm wondering if setting the name to a full path starting from root could
be used to change atomically the directory of a file (given the write
permission on both original and target directory).
Obviously I'm not
Hi, I'm wondering about the validity of an interpretation of intro(5) and
stat(5) that could allow a server to atomically change the directory of a
file.
From intro(5) http://man.cat-v.org/9front/5/intro
The notation
string[s] (using a literal s character) is shorthand for
s[2] followed by s
27 matches
Mail list logo
