Nate Diller wrote on Tue, 25 Jul 2006 09:22:01 -0700:
> On 7/25/06, Timothy Webster <[EMAIL PROTECTED]> wrote:
> > ===
> > My question
> > ===
> > How should directory mime types be recorded?
> > What is the standard?
>
> there's no standard for this
Hans Reiser wrote on Sun, 29 Jan 2006 23:15:41 -0800:
> When you use a return value #define for two different meanings,
> is there a name for that? It is generally accepted to be bad
> style, yes?
It might be called something overloading, perhaps Semantic Overloading?
- Alex
Peter Foldiak wrote on Sat, 03 Dec 2005 10:54:31 +:
> But why do we need a new type of file? What can you do with it that you
> absolutely couldn't without?
That's how I would do it, keep the namespace simpler. The new file/directory
for attributes would only perhaps be useful for backwards
Leo Comerford wrote on Fri, 18 Nov 2005 03:42:50 +:
> [^.*$]
Just a few points I thought of while reading through your text:
Genealogy is an extremely structured arrangement of data, most people won't be
doing something that complex - think of photo filing instead. Also cycles
exist everywhe
Peter van Hardenberg wrote on Wed, 09 Nov 2005 03:20:32 -0800:
> Odd Behavior:
> --
>
> Regression problems immediately spring to mind:
> [EMAIL PROTECTED]:~/reiser/test $ cd
> [EMAIL PROTECTED]:~/reiser/test/ $ cd
> [EMAIL PROTECTED]:~/reiser/test// $ cd
John Gilmore wrote on Thu, 27 Oct 2005 12:41:50 +:
> I'm failing to see the difference between a "true path" and a "not guaranteed
> true path" -- Don't all paths (that point "upwards") have to lead to root
> eventually? Hrm... Maybe you mean that an "upward path" (also called a "back
> refe
John Gilmore wrote on Wed, 26 Oct 2005 17:02:06 +:
> I had understood that a big part of the issue with file-as-directory was the
> same as the issue with hard links to directories. Which I thought is that if
> you move one directory into another, you can lose the connection to the root
> of
Leo Comerford wrote on Wed, 24 Aug 2005 07:51:19 +0100:
> Firstly, I apologise for the absurdly late reply!
That's OK, my reply is also a bit late due to summer vacations.
> One workaround is to append a different, meaningless extra segment to
> each of their date_taken path"names", so one photo
Jonathan Briggs wrote on Tue, 19 Jul 2005 16:00:23 -0600:
> On Tue, 2005-07-19 at 22:09 +0200, Ragnar Kjørstad wrote:
> > Readdir will return the filenames in hash order. Find will then go and
> > stat each file, still in hash order.
> >
> > Problem is, the inodes are not sorted in directory hash
Hans Reiser wrote on Tue, 05 Jul 2005 16:56:02 -0700:
> One can have hardlinks to a directory without cycles provided that one
> does not have hardlinks from the children of that directory to any file
> not a child of that directory. (Mountpoints currently implement that
> restriction.)
>
> Quest
Nikita Danilov wrote on Fri, 3 Jun 2005 15:15:08 +0400:
> This is exactly what some application do. Here is how transactions can
> be implemented in the POSIX file system:
>
> - you have a symlink ./d.active pointing to the "current" directory
> under which some sub-tree of interest is located;
Nikita Danilov wrote on Thu, 2 Jun 2005 14:03:54 +0400 in the
"Re: File as a directory - VFS Changes" thread:
> This is typical operation for a desktop usage, I agree. But desktop is
> not interesting. It doesn't pose technical difficulty to implement
> whatever indexing structure when your dataset
Nikita Danilov wrote on Wed, 1 Jun 2005 14:58:47 +0400:
> For example: mv /d0 /d1
>
> To check that this doesn't introduce a cycle one has to load each child
> of /d0 (which may be millions) and recursively check that from none of
> them /d1 is reachable. This has to be done on each rename. I beli
Hans Reiser wrote on Tue, 31 May 2005 11:32:04 -0700:
> What about if we have it that only the first name a directory is created
> with counts towards its reference count, and that if the directory is
> moved if it is moved from its first name, the new name becomes the one
> that counts towards the
Nikita Danilov wrote on Tue, 31 May 2005 13:34:55 +0400:
> Cycle may consists of more graph nodes than fits into memory. Cycle
> detection is crucial for rename semantics, and if
> cycle-just-about-to-be-formed doesn't fit into memory it's not clear how
> to detect it, because tree has to be locked
Nikita Danilov wrote on Mon, 30 May 2005 15:00:52 +0400:
> Nothing in VFS prevents files from supporting both read(2) and
> readdir(3). The problem is with link(2): VFS assumes that directories
> form _tree_, that is, every directory has well-defined parent.
At least that's one problem that's solv
[EMAIL PROTECTED] wrote on Sat, 28 May 2005 15:42:35 -0400:
> I'm not Hans, but I *will* ask "How much of this is *rationally* doable
> without some help from the VFS?". At the very least, some of this stuff
> will require the FS to tell the VFS to suspend its disbelief (for starters,
> doing this
Leo Comerford wrote on Wed, 18 May 2005 12:50:38 +0100:
> But if you have relation-directories and the ability to find the
> pathnames of a given file, you can do everything you can do with
> subfiles, just as nicely, and more besides. And if subfiles are
> completely redundant and bad news anyway,
David Masover wrote on Tue, 17 May 2005 17:51:20 -0500:
> How much of a price do I pay? And could that price be avioded by only
> enabling those features for directories where I want them? Could that
> be done easily in Reiser4?
Interesting point. A lot of those features require that file syste
Leo Comerford wrote on Mon, 16 May 2005 13:32:19 +0100:
> Probably the biggest barrier is the fact that it's nigh-impossible to
> take a specific (non-directory) file and find its pathnames! We need
> the ability to do this for any file, directory or otherwise, and for
> all types of pathnames appl
Fred Schaettgen wrote on Sat, 1 Jan 2005 12:56:33 +0100:
> Do you know if this service was actually provided by the file system or was
> it
> just a clever use of a more simple feature of the fs which allows to do that?
> There are certainly a lot of things which could be done, if changed files c
Fred Schaettgen wrote on Sat, 1 Jan 2005 01:43:48 +0100:
> The file system itself could help for instance by providing a new
> "change-monitor"-flag for a file. This flag would be set only from userspace
> and reset when the file is modified. If the flag is still set when the file
> is being mod
Fred Schaettgen wrote on Fri, 31 Dec 2004 10:47:14 +0100:
> The purpose btw. is to find all modified files in a tree as fast as possible.
> There are quite a lot of application which would benefit from it: desktop
> search engines, locate, build systems, tools which visualize contents of a
> fil
Horst von Brand wrote on Tue, 21 Dec 2004 13:29:46 -0300:
> How does the user know that this is a directory cycle being removed? Also,
> while I nuke a particular link into the cycle, somebody else could be
> creating a new one...
The error code would tell you. If someone else is adding links whi
David Masover wrote on Mon, 20 Dec 2004 23:31:53 -0600:
> Would it work in a typical setup? My instinct is no.
Depends on how big the directory loop and attached files are (basically all
the descendants of the directory you're trying to delete). In most cases,
you don't have millions of director
Hans Reiser wrote on Mon, 20 Dec 2004 09:21:35 -0800:
> Ok, go talk to the befs driver guy, and you'll find out he has already
> done work on it.
I just did some work in making a test file system with hard links and
bidirectional references (files know which directories (plural) they are in).
It
Hans Reiser wrote on Mon, 30 Aug 2004 23:43:13 -0700:
> Alexander G. M. Smith wrote:
> >Are you sneaking in file types there? Just how does a file know which
> >plugins it supports?
>
> we have plugins with pluginids, is that what you mean by file type? I
> think they
Will Dyson wrote on Mon, 30 Aug 2004 21:57:17 -0400:
> I had a look. Cool stuff!
Thanks!
> That is a pretty awesome idea. It should be done in its own specialized
> filesystem though. QueryFS. If the change-notification mechanism in the
> kernel was robust enough (a big if), the rest could be don
Hans Reiser wrote on Sun, 29 Aug 2004 13:21:44 -0700:
> The Idea [...] Conclusion
Good summary!
> The Idea 2: [...]
> cat filename/pseudos/backup gives a set of commands that a backup
> command can use to create the file "filename" [...]
Are you sneaking in file types there? Just how does a fil
Linus Torvalds wrote:
> I'm pretty confident that we can extend the VFS layer to support
> named streams [...]
Hans Reiser wrote on Sat, 28 Aug 2004 15:29:33 -0700:
> I object to openat().
>
> My reason is that the things that distinguish between objects should be
> the names, not the choice
Will Dyson wrote on Fri, 27 Aug 2004 14:20:29 -0400:
> Hans Reiser wrote:
> > Will Dyson wrote:
> >> In the original BeOS, they solved the problem by having the filesystem
> >> driver itself take a text query string and parse it, returning a list
> >> of inodes that match. The whole business of p
Burnes, James wrote on Wed, 21 Apr 2004 17:10:00 -0600:
> In the same way that 'ls ' is ambigous. Does it mean I want
> to look at the attributes of the directory itself, or does it mean that
> I'm referring to the contents of the directory? That's why they
> invented 'ls -d'
Good analog. There
Elliott Mitchell wrote on Fri, 16 Apr 2004 19:55:54 -0700 (PDT):
> > From: Grant Miner <[EMAIL PROTECTED]>
> > I like "metas".
>
> Chalk me up as neutral about the name itself. That is I'm neutral about
> ".metas" or "..metas", I'm firmly against using "metas" (or any other
> name) without at leas
Christian Iversen wrote on Mon, 5 Apr 2004 02:12:05 +0200:
> Just a thought. Who on this list does NOT support "..." instead of metas?
Windows has that as the parent of the parent directory.
I also use it as the second parent directory in a file system that allows multiple
parents, is the t
Elliott Mitchell wrote on Wed, 31 Mar 2004 21:46:14 -0800 (PST):
> Also I feel it should be on the file itself. ie for the file /tmp/fooblah
> you should be able to access the file's metadata by open()ing/using
> readdir() on /tmp/fooblah/metas or (/tmp/fooblah/..metas or whatever).
Sounds good to
David Masover wrote on Thu, 18 Mar 2004 17:04:30 -0600:
> | David> What about a reiser4 plugin?
> |
> | I would think that would count as being in the filesystem level.
>
> Yet it doesn't involve writing a *new* filesystem, which is I think what
> was being suggested? Alexander?
I was concerned
faraz ahmed wrote on Tue, 16 Mar 2004 14:45:23 -0800 (PST):
> Each Directory Structure is a XML file
> discribing the directory structure as well as the
> attributes of the Files to be listed under Each
> directory. The file system the mounts this XML file &
> produces the directory listing by quer
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 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
[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
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
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 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
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
Hans Reiser wrote on Sun, 24 Aug 2003 21:35:57 +0400:
>Helge Hafting wrote:
>>On Tue, Aug 05, 2003 at 03:03:51PM +0200, Stephan von Krawczynski wrote:
>>>On Tue, 05 Aug 2003 14:51:46 +0200 Helge Hafting <[EMAIL PROTECTED]> wrote:
Even more fun is when you have a directory loop like this:
>
Russell Coker wrote on Mon, 23 Dec 2002 14:21:52 +0100:
> Mail serving with Maildir storage.
Same sort of thing here. Thousands of e-mail and news files in
a directory, so displaying them in a GUI directory display window
can be slow. Particularly if it is also getting attributes to
display (fro
Hans wrote:
> http://plan9.bell-labs.com/sys/doc/lexnames.html
Interesting reading. I tackled the multiple parent directories
problem in my experimental RAM file system for BeOS by defining
"..", "...", "" and so on for each possible parent directory.
The ".." one is special in that it has a
Philipp Gühring <[EMAIL PROTECTED]> wrote on Fri, 8 Mar 2002 18:22:07
+0100:
> Well, I would like to have the following system:
> [...]
> # We create a bidirectional link between the two files 1 and 2
> >ln -B a c
OK, that kind of requires that a file also be a directory, otherwise
how would you
Philipp Gühring <[EMAIL PROTECTED]> wrote on Fri, 8 Mar 2002 09:58:58
+0100:
> Can you tell me more about the bidirectional links, you have
> in your filesystem?
>
> What is the exact semantic of it?
> Which problems do you try to solve with it?
It may be of interest to other people on the maili
In http://www.st-andrews.ac.uk/~lrc1/pathname_metadata.html
Leo Comerford <[EMAIL PROTECTED]> wrote on March 7 2002:
> [all-pathname-metadata system]
Complex, well thought out, but too complex for me! I'll go through
some points as seen from my BeOS BFS (Be File System) point of view.
The /..st
Hans Reiser <[EMAIL PROTECTED]> wrote
on Thu, 07 Mar 2002 12:16:51 +0300:
> The notion that we need to be able to delete metadata when we
> delete a file, and that this means we need two way links, is
> one I have been pondering for ~18 years though I did not
> address it in my paper.
Odd, I ran
In http://www.st-andrews.ac.uk/~lrc1/pathname_metadata.html
Leo Comerford <[EMAIL PROTECTED]> wrote on March 7 2002:
> The evil way is to create the illusion of infinite files through the use of
> cycles or some smart-alecry in the kernel.
Some things have to be atomic and not generic, type infor
Xuan Baldauf <[EMAIL PROTECTED]> wrote on Mon, 14 Jan 2002 03:56:00
+0100:
> No. Once you modify your applications to use the access form
> "foo.jpeg/content", files without attributes (files which have
> to be accessed using the old access form "foo.jpeg") won't be
> accessible anymore.
The tem
>If the kernel people can't fit it in, it can be hacked around.
>Perhaps have each object appear twice in directory listings (once
>as a file, once as a directory, perhaps with a slightly different
>name). Or have an alternate API via ioctl codes until it gets
>accepted as being worthy of the ker
Hubert Chan <[EMAIL PROTECTED]> wrote on 11 Jan 2002 20:44:44 -0500:
> I think that's the point of trying to figure out a prefix for the
> attributes -- so that attribute names in directories won't collide with
> file names. So if you want a thumbnail for your directory foo, you just
> do "cp ico
David L. Parsley <[EMAIL PROTECTED]> wrote on Fri, 04 Jan 2002 19:23:11 -0500:
> I'll agree that I initially thought the 'file as directory' idea had a
> very high cool factor - but Linus, Al Viro, etc. convinced me otherwise.
> This also makes me think you'll have a hard time getting the kernel
Andrew Clausen <[EMAIL PROTECTED]> wrote on Sat, 12 Jan 2002 09:25:18 +1100:
> For package types, it's really both a Debian package and an ar
> archive (yes?). Perhaps file(1) should know about such packages,
> and call an extracter, and reinvoke itself?
With the XML as a file system approach, t
toad <[EMAIL PROTECTED]> wrote on Sat, 12 Jan 2002 01:07:20 +:
>> The implementation detail is that the attribute/file/object type has
>> to be a special case, not a generic attribute. Perhaps a 32 bit integer
>> hidden in the underlying inodes. [...]
>
> A {sym,hard,COW}link?
What's a COW
Raphael Bosshard <[EMAIL PROTECTED]> forwarded a message on Mon, 07 Jan 2002
20:09:17 +0100,
it was originally from Daniel Veillard <[EMAIL PROTECTED]> on Mon, 7 Jan 2002
12:24:14 -0500,
and addressed to the Gnome 2.0 list:
> Yep, IMHO Mime-Type are slowing falling into obsolescence due to
> c
Chris Dukes <[EMAIL PROTECTED]> wrote on Mon, 7 Jan 2002 16:34:28 +:
> A wise person once said "those who do not know Unix are doomed
> to reinvent it, poorly." In the case of structured files, it
> would appear that those that do not know OS/400 are doomed to
> reinvent it, poorly.
Good poi
The Amazing Dragon (Elliott Mitchell) <[EMAIL PROTECTED]> wrote on Sat, 5 Jan 2002
16:26:21 -0800 (PST):
>[...] You need to be able to get *everything* for programs such as
> tar and cp, but then you've got ordinary programs that just want
> their data. My tendancy is that the prior suggestion of
Chris Dukes <[EMAIL PROTECTED]> wrote on Sun, 6 Jan 2002 01:40:51 +:
> 2) I see a lack of consensus about what sort of metadata should be
> grafted onto files, yet I already see questionable arbitrary
> limits appearing. Perhaps some of the advocates could make
> references to userspace rich
After a bit of thought, I've got a few more points about
The XML Object File System idea.
Minor point - the data of a file/object would be stored in an
attribute named "default-data" or "data" or maybe even "" (that's
the one old software gets when you don't specify an attribute when
opening an o
Hans Reiser <[EMAIL PROTECTED]> wrote on Sat, 05 Jan 2002 02:52:56 +0300:
> I think that with reiser4, we just need to settle on a style
> convention (what is it called, ..content-type or ..mime-type or
> ..type or.?) Do we need to write a plugin for it? I think
> maybe not, I am not sure th
Philipp Gühring <[EMAIL PROTECTED]> wrote on Sat, 5 Jan 2002 03:35:23 +0100:
> Then I would suggest using XML instead, (perhaps a special
> form of it). That would give the needed flexibility.
He also wrote in another message:
> I looked at MacOS and other ideas of attaching metadata to data,
>
Scott Simpson <[EMAIL PROTECTED]> wrote on Fri, 4 Jan 2002 17:13:54 -0800:
> [...] Is there any way to detect if a change has been made to a
> file such as data changing, a change in ownership, a permissions
> change, etc programmatically? I looked through the various file
> system source code in
69 matches
Mail list logo
