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 sort of
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
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
reference no?)
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 pathnames, so one photo is
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 order on
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.)
Question:
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 is
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 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 believe
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
[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, we
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 system
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 applied
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 can
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
file
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
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
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 are a bit different from file types
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 file
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 done
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 parsing a
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 of
Burnes, James wrote on Wed, 21 Apr 2004 17:10:00 -0600:
In the same way that 'ls directory' 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.
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 least a leading
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
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 that
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 querying
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 everything
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 just
[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 structures
[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-case
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,
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 a
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.
Saving
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
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
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:
mkdir A
cd A
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
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 find
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
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 /..stat
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 temporary
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 link?
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
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 kernel.
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 point. I
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
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 file
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 the
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 the
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,
but I
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 the
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
62 matches
Mail list logo
