[EMAIL PROTECTED] wrote:
the
linking directory should store both an identifier for the child file's
filesystem and the child file's on-disk inumber on that filesystem.* The
reverse
links would be stored in the same way.
I can accept a patch that does this.
I would su
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] wrote:
Quoting David Masover <[EMAIL PROTECTED]>:
[...]
[EMAIL PROTECTED] wrote:
[...]
The problem here is that if the link itself is on a different filesystem
than the actual data, and the original filesystem gets nuke
Quoting David Masover <[EMAIL PROTECTED]>:
[...]
> [EMAIL PROTECTED] wrote:
[...]
> >
> The problem here is that if the link itself is on a different filesystem
> than the actual data, and the original filesystem gets nuked, what do I
> do about the link? Traditionally, in order to delete a
Sent too soon by accident... sorry about that!
Leo.
-
University of St Andrews Webmail: http://webmail.st-andrews.ac.uk
Quoting David Masover <[EMAIL PROTECTED]>:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> [EMAIL PROTECTED] wrote:
>
> >Quoting Hans Reiser <[EMAIL PROTECTED]>:
> >
> >...
> >
> >
> >
> >>[EMAIL PROTECTED] wrote:
> >>
> >>
> >>
> >>>Sorry for the delay in replying.
> >>>
> >>>Quotin
The approaches nikita suggests don't seem very efficient for the no loop
case.
Hans
David Masover wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I will step aside and let the smart people figure this out. Only one
real suggestion -- most directories will not have loops. I'm not sure
> "Leo" == lrc1 <[EMAIL PROTECTED]> writes:
[...]
Leo> Second, before implementing hard linking across directories you're
^^^
I assume you meant "filesystems" there?
Leo> really going to need two-way links between directories and
David Masover wrote on Sat, 06 Dec 2003 19:08:51 -0600:
> Most of the time, rename over an existing file needs only a single
> deletion, and renaming over a directory is (last I checked) impossible
> with standard tools without removing or renaming the directory first.
Correct. But that's jus
> "David" == David Masover <[EMAIL PROTECTED]> writes:
[...]
David> I guess the main problem I have with this is that it only works
David> when we're talking about all the filesystems on the local
David> machine, and then only so far. It kind of falls apart with
David> removable filesystems
> "Leo" == lrc1 <[EMAIL PROTECTED]> writes:
[...]
Leo> The solution I suggest is to throw out the "one volume, one tree"
Leo> requirement. The volume's tree then becomes a forest, with every
Leo> file with no parent in the volume being the root of a tree.
[...]
Leo> Thus the answer to you
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] wrote:
...
The solution I suggest is to throw out the "one volume, one tree" requirement.
The volume's tree then becomes a forest, with every file with no parent in the
volume being the root of a tree. (Of course, if you also have mu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alexander G. M. Smith wrote:
David Masover wrote on Fri, 05 Dec 2003 19:54:26 -0600:
Incidentally, renaming files is a superset of the delete operation.
Implement that first, and you have delete for free.
If only it was that easy. When you r
Quoting Hans Reiser <[EMAIL PROTECTED]>:
> [EMAIL PROTECTED] wrote:
>
> >Quoting Hans Reiser <[EMAIL PROTECTED]>:
> >
> >...
> >
> >
> >
> >>[EMAIL PROTECTED] wrote:
[...]
> >>>
> >>>Quoting Hubert Chan <[EMAIL PROTECTED]>:
[...]
> >I would suggest that for every link to a file on a differe
Quoth Hubert Chan <[EMAIL PROTECTED]>:
...
>
> [1] This presents another problem to hardlinking across partitions.
> What if you try to hardlink a file from a read-only partition onto a
> read-write partition (or vice versa)? A hardlink is supposed to be
> essentially the same on both sides, so
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Yes. Mounting a partition read-only mainly protects against
accidentally doing something stupid. (e.g. "rm -rf /")
Good point. However, the usual way to do that is "alias rm='rm -i' or
to never give the root password to people who do things like
David Masover wrote on Fri, 05 Dec 2003 19:54:26 -0600:
> >Incidentally, renaming files is a superset of the delete operation.
> >Implement that first, and you have delete for free.
> >
> >
> If only it was that easy. When you rename a folder, you don't usually
> do a recursive rename of everyt
On Sat, 2003-12-06 at 03:18, Nikita Danilov wrote:
> http://citeseer.nj.nec.com/jones03garbage.html is a recent bibliography
> in this subject, containing more than 2 references. I am afraid this
> is little too much for a brief description. But basically, instead of
> reclaiming garbage when "
> "David" == David Masover <[EMAIL PROTECTED]> writes:
[...]
>> There's more to security and good administration than just disk
>> quotas. You can have different partitions mounted read-only.[1] You
>> have
>>
David> And how is that different than chmod -x? Root can remount a
David> partit
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Incidentally, renaming files is a superset of the delete operation.
Implement that first, and you have delete for free.
If only it was that easy. When you rename a folder, you don't usually
do a recursive rename of everything inside. When you del
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I will step aside and let the smart people figure this out. Only one
real suggestion -- most directories will not have loops. I'm not sure
how, but I'd imagine it's possible to use refcounts there and other
forms of garbage collection elsewhere. I
Oops, found this in my drafts box after a long time had passed.
Hans
[EMAIL PROTECTED] wrote:
Sorry for the delay in replying.
Quoting Hubert Chan <[EMAIL PROTECTED]>:
"Leo" == lrc1 <[EMAIL PROTECTED]> writes:
[...]
Why? Not at all, I would say.
Leo> Shor
[EMAIL PROTECTED] wrote on Fri, 10 Oct 2003 02:02:05 +0100:
> Should Cedric create photos/people/happy/good/ which links back to
> photos/people/happy/ , or should he create photos/people/good/happy/ ,
> which links back to photos/people/good/ ?)
Sure, you could have non-cyclic directory structure
Sorry for the delay in replying.
Quoting Hubert Chan <[EMAIL PROTECTED]>:
> > "Leo" == lrc1 <[EMAIL PROTECTED]> writes:
>
> [...]
>
> >> Why? Not at all, I would say.
>
> Leo> Short answer: because otherwise you have ""attributes" that cannot
> Leo> interact with files in all the same wa
Quoting "Alexander G. M. Smith" <[EMAIL PROTECTED]>:
> [EMAIL PROTECTED] wrote on Mon, 22 Sep 2003 14:28:30 +0100:
> > * Will
> >
> > chmod u-rwx somefile; chmod u+rwx somefile
> >
> > still work? What special-case behaviour will be needed to make it work?
>
> Likely via the Janus (two fa
Narcoleptic Electron wrote on Mon, 22 Sep 2003 11:53:28 -0400 (EDT):
> I've attempted to codify the criteria to be used in deciding a name for the
> attributes directory.
Sounds like you have it covered. I'd add "easy to type", though you said no keyboard
placements should be considered. Still
[EMAIL PROTECTED] wrote on Mon, 22 Sep 2003 14:28:30 +0100:
> I'm back to play Banquo's ghost. This talk about syntax is all very well, but
> does anyone have answers for questions like the following:
>
> * Will
>
> chmod u-rwx somefile; chmod u+rwx somefile
>
> still work? What special-ca
I've compiled all the name suggestions that are still standing (and added some more -
more suggestions welcome). The list so far:
Object/,,/Attribute
Object/+/Attribute
Object/@/Attribute
Object/_/Attribute
Object/^/Attribute
Object/=/Attribute
Object/()/Attribute
Object/(...)/Attribute
Object/
I've attempted to codify the criteria to be used in deciding a name for the attributes
directory.
1. Cannot contain reserved file system characters on any system.
2. Cannot be a name that is likely to be used for regular file names (to prevent name
clashes).
3. Should not contain characters tha
I'm back to play Banquo's ghost. This talk about syntax is all very well, but
does anyone have answers for questions like the following:
* Will
chmod u-rwx somefile; chmod u+rwx somefile
still work? What special-case behaviour will be needed to make it work?
* Will it be possible to mak
Narcoleptic Electron wrote:
There is no reason why an attribute directory couldn't itself have an attribute directory. It is just another directory. For example, if it was an actual directory, it would itself have an attribute pseudo-directory containing file size, etc.
The attribute directory
There is no reason why an attribute directory couldn't itself have an attribute
directory. It is just another directory. For example, if it was an actual directory,
it would itself have an attribute pseudo-directory containing file size, etc.
The attribute directory needs to be a subdirectory
Bennett Todd wrote on Fri, 19 Sep 2003 09:46:31 -0400:
> If someone were to want to attach an icon to a directory describing
> what it contained, that'd be an opposite case; stat should still
> report the internal node as a directory, you shouldn't see the icon
> unless you explicitly tried to open
Martin Wilck <[EMAIL PROTECTED]> wrote:
Subject: Re: Carrying Attributes too Far
From: Martin Wilck
To: Narcoleptic Electron
Date: 19 Sep 2003 18:06:59 +0200
Am Fre, 2003-09-19 um 17.48 schrieb Narcoleptic Electron:
> [martin]
> The question is if that tradition is really so
... Or we could use a smiley: ;-)
That way typing paths in ReiserFS would make people feel happy.
(I'm joking)
[martin]
The question is if that tradition is really so important in this
context. Will that file name be typed more often than, say,
'.xsession-errors' or '.nautilus-metafile.xml'?
Martin Wilck wrote on 19 Sep 2003 17:13:12 +0200:
> Call it .metadata if you wish. I just wanted to say that a reasonable
> English name will be easier to understand than ".," for almost
> everybody.
Normally I'm a fan of long names, so .metadata is good, or .attributes would also work.
> > Savin
Am Fre, 2003-09-19 um 15.27 schrieb Alexander G. M. Smith:
> > What about '"' or even ' '?
>
> No, they cause problems with various shell special characters.
> So you'd have to escape them with a preceeding backslash if you used
> them. That's awkward (even more than using a shifted letter lik
2003-09-18T17:44:13 Alexander G. M. Smith:
> They need to be hidden sometimes. [...] Or be prepared for them to
> make a mess, like storing all their e-mail inside an attribute on
> an e-mail icon.
And that thought provoked some pondering in me.
I've been thinking about these new semantics in Rei
Martin Wilck wrote on 19 Sep 2003 10:42:35 +0200:
> Hey folks, I know it's not my business, but '...', ,',,', '_', '!', '@',
> '-' ... is this really a serious discussion? What about '"' or even ' '?
No, they cause problems with various shell special characters. So you'd have to
escape them with
Narcoleptic Electron wrote on Fri, 19 Sep 2003 00:40:42 -0400 (EDT):
> I agree... two commas are much easier to type. I think it is still a little hard to
> read, though. I'm also not convinced on aesthetic grounds... commas don't look like
> stand-alone entities to me, and they're not symmetri
Hans Reiser wrote on Thu, 11 Sep 2003 19:18:55 +0400:
> I think that a distinction between attributes and contained objects can
> only be a style convention, because for some objects/attributes there is
> no proper division.
>
> However, you might be right that the style convention should be a
> su
40 matches
Mail list logo
