our 2.6.17 patch is not stable, please be warned

our 2.6.17 patch is not stable, please be warned

[Hans Reiser]

It crashed on me, and needed an fsck.  At least our fsck works well
though:-/, Vitaly, you did a great job of making the user interface
informative.

Hans

Viewing files as directories

[Timothy Webster]

WARNING, a users point of view ;)
Everything is a file, including a directory.

Being able to view files as directories is not just a
nice to have thing. It is actually required if we are
going to manage changesets of odf files.

Changesets are wonderfultool we have as developers to
assist as a community to develop huge complex code.
The truth is most people aren't code developers, but
document developers. odf files are a container. And it
is handy for users to see them as just a single file.
But just about just about every program or script
would be better off seening the odf as a compressed
directory.

Yes it would be really wonderful, if we could just see
directories as file and files as directories. Which of
course means a file and a directory are one in the
same.

As things stand now the way forward seams to be per
application program mime types. Simple right, but it
is not because, applications tools like svn, brz,
darcs, etc. Can't understand that directory checked is
just a odf file. For the basic rule of a file is a
directory and a directory is a file to be true.
Directories need to have mime types too. 

===========================
My question
===========================
How should directory mime types be recorded?
What is the standard?


-Tim.




__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: Viewing files as directories

[Nate Diller]

On 7/25/06, Timothy Webster <tdwebste2@yahoo.com> wrote:
> WARNING, a users point of view ;)
> Everything is a file, including a directory.
>
> Being able to view files as directories is not just a
> nice to have thing. It is actually required if we are
> going to manage changesets of odf files.
>
> Changesets are wonderfultool we have as developers to
> assist as a community to develop huge complex code.
> The truth is most people aren't code developers, but
> document developers. odf files are a container. And it
> is handy for users to see them as just a single file.
> But just about just about every program or script
> would be better off seening the odf as a compressed
> directory.
>
> Yes it would be really wonderful, if we could just see
> directories as file and files as directories. Which of
> course means a file and a directory are one in the
> same.
>
> As things stand now the way forward seams to be per
> application program mime types. Simple right, but it
> is not because, applications tools like svn, brz,
> darcs, etc. Can't understand that directory checked is
> just a odf file. For the basic rule of a file is a
> directory and a directory is a file to be true.
> Directories need to have mime types too.
>
> ===========================
> My question
> ===========================
> How should directory mime types be recorded?
> What is the standard?

there's no standard for this sort of thing, but the Be file system did
this, maybe it's the 'standard' cause no one else has really even
tried.  either way, the book about it is *very* worthwhile, and these
days is free

http://haiku-os.org/downloads.php?mode=view_dl&id=7

NATE

Re: Viewing files as directories

[Alexander G. M. Smith]

Nate Diller wrote on Tue, 25 Jul 2006 09:22:01 -0700:
> On 7/25/06, Timothy Webster <tdwebste2@yahoo.com> wrote:
> > ===========================
> > My question
> > ===========================
> > How should directory mime types be recorded?
> > What is the standard?
> 
> there's no standard for this sort of thing, but the Be file system did
> this, maybe it's the 'standard' cause no one else has really even
> tried.  either way, the book about it is *very* worthwhile, and these
> days is free
> 
> http://haiku-os.org/downloads.php?mode=view_dl&id=7

Apple developed their own file typing system.  It's more of a class hierarchy
than MIME types.  Have a look at "Uniform Type Identifiers", a good
description is at http://arstechnica.com/reviews/os/macosx-10.4.ars/11

Maybe there's a standard cluster of UTIs there for containers, like
directories.  By the way BeOS had directories identified with a MIME
type of application/x-vnd.Be-directory and there were other ones for
disk volumes and the like.

- Alex

Re: Viewing files as directories

[David Masover]

[-- Attachment #1: Type: text/plain, Size: 3532 bytes --]

Timothy Webster wrote:
> WARNING, a users point of view ;)
> Everything is a file, including a directory.
> 
> Being able to view files as directories is not just a
> nice to have thing. It is actually required if we are
> going to manage changesets of odf files.

The lkml people will tell you that this isn't required at all, and it's
ludicrous to say so.  And they're somewhat right -- you could just patch
SVN, and it might be easier than writing a Reiser4 plugin.

> The truth is most people aren't code developers, but
> document developers. odf files are a container. And it
is XML inside.

Come on, do you really expect people to read XML diffs?  Even if you
split the XML out into files/dirs based on elements, using SVN directly
would be way too arcane to people who are used to what word processors
already do -- it's something called "Track Changes".

Fire up OpenOffice and check out the Edit->Changes menu.  Word has a
similar feature.  Not as powerful, maybe, but most people are not
collaborative document developers, either.

> But just about just about every program or script
> would be better off seening the odf as a compressed
> directory.

Maybe, maybe not.

> Yes it would be really wonderful, if we could just see
> directories as file and files as directories. Which of
> course means a file and a directory are one in the
> same.

Ever use OS X?  It does this, to some extent, in Finder, which supports
the lkml point that doing this in the filesystem, or anywhere in the
kernel, is unnecessary and a bad idea.

> As things stand now the way forward seams to be per
> application program mime types. Simple right, but it
> is not because, applications tools like svn, brz,

There are two OS X file types that I know of, and probably quite a few
more, which are actually stored on disk as folders, which is why most
Mac software is distributed as disk images or zipfiles.  One is the
Application type (.app, though Finder hides the extension) and the other
is the MPKG type (whatever it stands for, extension is .mpkg).

Basically, they appear as ordinary files to Finder, which means that
most of the time, you cannot see that there are files inside them.  You
double click on a .app, and it runs a script in a predefined relative
location inside the folder.  Double click on a .mpkg, and it launches
their installer program.  Drag them around and they behave like files in
every way, except that you cannot email them, upload them to a web page,
or interact with anywhere other than your local Mac system which expects
single files.  But when you run into that, just zip them.

But if you want, you can right-click on them (or control+click) and -- I
forget which option it is, but you can browse inside the package.



By the way, Hans, Apple has beaten you by quite a bit for at least some
of the functionality we've discussed.  You can do operations on Search
Folders easily, which work by using Spotlight (an indexed fulltext local
system search engine).  You can have files-as-directories, to a point.
There are generic ways of getting at metadata, and they are done as
plugins -- Spotlight plugins, anyway.

I'd much rather use the Reiser4 described in the whitepaper, of course,
and I am getting sick of the lack of decent package management for my
Mac, so I'll be adding a Linux boot.  I'm curious to see if Reiser4 is
stable on PowerPC -- this is a year-old G4, I missed the Intel cores by
just a few short months...


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 890 bytes --]

Re: Viewing files as directories

[Toby Thain]

On 25-Jul-06, at 8:08 PM, David Masover wrote:

> Timothy Webster wrote:
> ...
>> Yes it would be really wonderful, if we could just see
>> directories as file and files as directories. Which of
>> course means a file and a directory are one in the
>> same.
>
> Ever use OS X?  It does this, to some extent, in Finder, which  
> supports
> the lkml point that doing this in the filesystem, or anywhere in the
> kernel, is unnecessary and a bad idea.
>
>> As things stand now the way forward seams to be per
>> application program mime types. Simple right, but it
>> is not because, applications tools like svn, brz,
>
> There are two OS X file types that I know of, and probably quite a few
> more, which are actually stored on disk as folders,

Apple calls them "packages": http://developer.apple.com/documentation/ 
DeveloperTools/Conceptual/SoftwareDistribution/Managed_Installs/ 
chapter_5_section_2.html

(I actually thought they were called "bundles", but as the following  
page explains, "The term bundle indicates a directory with a specific  
hierarchical structure, whereas the term package indicates a  
directory that is treated as an opaque entity by the Finder.")
http://developer.apple.com/documentation/CoreFoundation/Conceptual/ 
CFBundles/Concepts/about.html


> which is why most
> Mac software is distributed as disk images or zipfiles.  One is the
> Application type (.app, though Finder hides the extension) and the  
> other
> is the MPKG type (whatever it stands for, extension is .mpkg).

Apart from .pkg and .mpkg, bundle extensions are also treated  
specially including .bundle, .component, .qtx, etc.

>
> Basically, they appear as ordinary files to Finder, which means that
> most of the time, you cannot see that there are files inside them.   
> You
> double click on a .app, and it runs a script in a predefined relative
> location inside the folder.  Double click on a .mpkg, and it launches
> their installer program.  ...
>
> By the way, Hans, Apple has beaten you by quite a bit for at least  
> some
> of the functionality we've discussed.  You can do operations on Search
> Folders easily, which work by using Spotlight (an indexed fulltext  
> local
> system search engine).

Apparently running SQLite underneath.

> You can have files-as-directories, to a point.
> There are generic ways of getting at metadata, and they are done as
> plugins -- Spotlight plugins, anyway.
>
> I'd much rather use the Reiser4 described in the whitepaper, of  
> course,
> and I am getting sick of the lack of decent package management for my
> Mac, so I'll be adding a Linux boot.  I'm curious to see if Reiser4 is
> stable on PowerPC -- this is a year-old G4, I missed the Intel  
> cores by
> just a few short months...
>

Re: Viewing files as directories

[Toby Thain]

On 25-Jul-06, at 8:08 PM, David Masover wrote:

> Timothy Webster wrote:
> ...
>> Yes it would be really wonderful, if we could just see
>> directories as file and files as directories. Which of
>> course means a file and a directory are one in the
>> same.
>
> Ever use OS X?  It does this, to some extent, in Finder, which  
> supports
> the lkml point that doing this in the filesystem, or anywhere in the
> kernel, is unnecessary and a bad idea.
>
>> As things stand now the way forward seams to be per
>> application program mime types. Simple right, but it
>> is not because, applications tools like svn, brz,
>
> There are two OS X file types that I know of, and probably quite a few
> more, which are actually stored on disk as folders,

Apple calls them "packages": http://developer.apple.com/documentation/ 
DeveloperTools/Conceptual/SoftwareDistribution/Managed_Installs/ 
chapter_5_section_2.html

(I actually thought they were called "bundles", but as the following  
page explains, "The term bundle indicates a directory with a specific  
hierarchical structure, whereas the term package indicates a  
directory that is treated as an opaque entity by the Finder.")
http://developer.apple.com/documentation/CoreFoundation/Conceptual/ 
CFBundles/Concepts/about.html


> which is why most
> Mac software is distributed as disk images or zipfiles.  One is the
> Application type (.app, though Finder hides the extension) and the  
> other
> is the MPKG type (whatever it stands for, extension is .mpkg).

Apart from .pkg and .mpkg, bundle extensions are also treated  
specially including .bundle, .component, .qtx, etc.

>
> Basically, they appear as ordinary files to Finder, which means that
> most of the time, you cannot see that there are files inside them.   
> You
> double click on a .app, and it runs a script in a predefined relative
> location inside the folder.  Double click on a .mpkg, and it launches
> their installer program.  ...
>
> By the way, Hans, Apple has beaten you by quite a bit for at least  
> some
> of the functionality we've discussed.  You can do operations on Search
> Folders easily, which work by using Spotlight (an indexed fulltext  
> local
> system search engine).

Apparently running SQLite underneath.

> You can have files-as-directories, to a point.
> There are generic ways of getting at metadata, and they are done as
> plugins -- Spotlight plugins, anyway.
>
> I'd much rather use the Reiser4 described in the whitepaper, of  
> course,
> and I am getting sick of the lack of decent package management for my
> Mac, so I'll be adding a Linux boot.  I'm curious to see if Reiser4 is
> stable on PowerPC -- this is a year-old G4, I missed the Intel  
> cores by
> just a few short months...
>