Christian Mayrhuber wrote:
//http://somehost:port/foo/bla
While we're here, I'll point out that http://somehost/foo/bla and
http://somehost/foo/bla/ are valid, distinct URLs.
If http://somehost/foo/bla/ exists, many HTTP servers will return it
as the target of a redirect for
Alan Cox wrote:
On Mer, 2004-09-01 at 21:16, Jamie Lokier wrote:
(For example, if I edit an HTML file which is encoded in iso-8859-1,
change it to utf-8 and indicate that in a META element, and save it
under the same name, the full content-type should change from
text/html; charset=iso
Christer Weinigel wrote:
Can be done with dnotify/inotify and a cache daemon keeping track of
mtime. Yes, this will need a kernel change to make sure mtime always
changed when the file changes, but it does not require anything else.
- Can the daemon keep track of _every_ file on my disk
Tonnerre wrote:
I'll write you a small daemon based on libmagic which stores the
file attributes in xattrs, or if they're not supported, in some
MacOS/Xish per-directory files. Even a file manager (finder) can
do that, there's not even the need for a daemon.
Jamie Lokier wrote
Andrew Morton wrote:
No. All of the applications which you initially identified can be
implemented by putting the various bits of data into a single file and
getting applications to agree on the format of that file.
For example, some image file formats already support embedded metadata, do
Christer Weinigel wrote:
all applicatons that copy files will fail to copy the streams. So
no working cp command, no nautilus nor konqueror without changes to
the application.
No true. A lot of the fancy stuff depends on metadata which is merely
another view of the serialised contents in the
Christophe Saout wrote:
I think Hans' idea is (I don't know if it is a good idea nor if it is
doable, but at least it sounds interesting) to have special compound
files where you can do something like this:
cp text.txt test.compound/test.txt
cp image.jpg test.compound/image.jpg
And if
Christophe Saout wrote:
I'm just thinking about something. While you can't cut bytes out of unix
iles a lot of filesystems can do this (holes). Most of them only on a
block boundary, reiser4 on a byte boundary. If the filesystems could
export this functionality using an enhanced API we could
Christoph Hellwig wrote:
There's bound to be some security issue, but I'm not sure what you're
getting at with /tmp. What sort of sort of security problem arises
with a world-writeable directory such as /tmp, that cannot arise with
the standard fs semantics?
Actually you are right on
Christoph Hellwig wrote:
Unfortunately, the problem is that reiser4 is the only filesystem
which is _technically capable_ of implementing that abstraction in a
practical way, apparently. (I'm not sure if this is really true.
reiser4's object model is not the same as paths and inodes, but
Linus Torvalds wrote:
Well, you _could_ make it do a tar, but what's the point? That really
doesn't add any value as far as user space is concerned.
Think of it this way: if the directory and the default stream associated
with it aren't independent, then user space already has the
Rik van Riel wrote:
What do we do with O_CREAT ?
Do we always allow both a directory and a file to be created with
the same name ?
I haven't analysed it thoroughly. I suspect it's fine as long as:
(1) O_CREAT creates something with file-like
attributes, meaning stat() says it's a
Linus Torvalds wrote:
It is not the kernel which decides. The filesystem containing
/dev/hda/part1 opens the directory branch.
But that filesystem cannot know what the _other_ filesystem configurations
are. And that's what you'd have to have to mount.
At which point, userspace comes in.
Joel Becker wrote:
On Thu, Aug 26, 2004 at 01:49:15AM -0700, Hans Reiser wrote:
Yes, this was part of the plan, tar file-directory plugins would be cute.
Question: Is cat /foo/bar/baz.tar.gz/metas the attribute
directory or a directory in the tarball named metas?
This needs to be
Matt Mackall wrote:
Anything that currently stores a file's metadata in another file really
wants this right now. Things like image thumbnails, document summaries,
digital signatures, etc.
That is _highly_ debatable. I would much rather have my cp and grep
and cat and tar and such
I've never wrote I made my guesses from the CPU percentage alone, you
explained correctly why. I encourage you too to calculate yourself how
much more CPU time reiser4 needs.
Ok, fair enough :)
-- Jamie
16 matches
Mail list logo
