Will Reiser4 support a "hidden" attribute?

Will Reiser4 support a "hidden" attribute?

[Guido Schimmels]

I would like to have some clarification about this section from  
namesys.com:

"Hidden Directory Entries

A file can exist but not be visible when using readdir in the usual  
way. WAFL does this with the .snapshots directory; it works well for  
them without disturbing users. This is useful for adding access to a  
variety of new features and their applications without disturbing the  
user when they are not relevant."

This paragraph has been drastically pruned since the last time I was  
reading it. Back then it went ahead asking if people wanted hidden  
files like fat, ntfs and HFS always had. From the way this section has  
been shortened I take it, this feature has indeed found its way into  
Reiser4? This would be fantastic! I'm planning to use Reiser4 for my  
Desktop Linux project. I need this feature to hide the Unix legacy tree  
like MacOS X does it and (back then) BeOS.

What would be the command to hide/unhide a file?

Re: Will Reiser4 support a "hidden" attribute?

[Stewart Smith]

On Thu, 2003-11-20 at 11:58, Guido Schimmels wrote:
> Reiser4? This would be fantastic! I'm planning to use Reiser4 for my  
> Desktop Linux project. I need this feature to hide the Unix legacy tree  
> like MacOS X does it and (back then) BeOS.

Note that MacOS X actually accomplishes this by the GUI having a list
(inside a file named '.hidden') of things not to show.

On my OSX partition, the contents of .hidden is:
automount
bin
cores
Desktop DB
Desktop DF
Desktop Folder
dev
etc
lost+found
mach
mach_kernel
mach.sym
opt
private
sbin
tmp
Trash
usr
var
VM Storage
Volumes


Also, you'll notice that dot files are also hidden it the GUI.

A patch to nautilus to do this would be pretty simple, although then you
get into the problems of hiding a lot of stuff from the user (which you
may not want to).

OSX has the /System and /Library hierarchies that are familiar (enough)
to mac users, and the only parts that are really hidden is all that UNIX
stuff.

Maybe a gnome-vfs layer that interfaced with the packaging system would
make things a bit easier for newbies? i.e. essentially a drag-and-drop
version of apt and dpkg?

If you had a seperate hidden attribute (as well as the dot files
convention) you'd have a lot of old-hat unix people not looking for such
things, and when a 'ls -a' didn't show them, they'd assume they weren't
there. Not good for security.

Although, for things like .snapshot, which are file system provided,
such an approach works fine.

Re: Will Reiser4 support a "hidden" attribute?

[Guido Schimmels]

Am 20.11.2003 06:18:44 schrieb(en) Stewart Smith:
> On Thu, 2003-11-20 at 11:58, Guido Schimmels wrote:
> > Reiser4? This would be fantastic! I'm planning to use Reiser4 for  
> my
> 
> > Desktop Linux project. I need this feature to hide the Unix legacy
> tree
> > like MacOS X does it and (back then) BeOS.
> 
> Note that MacOS X actually accomplishes this by the GUI having a list
> (inside a file named '.hidden') of things not to show.
> 
> On my OSX partition, the contents of .hidden is:
> automount
> bin
> cores
> Desktop DB
> Desktop DF
> Desktop Folder
> dev
> etc
> lost+found
> mach
> mach_kernel
> mach.sym
> opt
> private
> sbin
> tmp
> Trash
> usr
> var
> VM Storage
> Volumes
>
> 
> Also, you'll notice that dot files are also hidden it the GUI.
> 
> A patch to nautilus to do this would be pretty simple, although then
> you
> get into the problems of hiding a lot of stuff from the user (which
> you
> may not want to).

In fact I've created such a patch for ROX-Filer.

My /.hidden file look like that:

bin
sbin
dev
etc
initrd
lib
lost+found
misc
mnt
home
halt
fastboot
opt
proc
sys
system
tmp
usr
var
uri


But that's only for demonstration purposes. It works Aqua, but not for  
X11 with its multitude of toolkits. Even though my OS is focussed on  
the Gnome developer platform, the occasional Qt, Tk, Motif, Java/Swing  
app is inevitable. Too much work creating and maintaining file-selector  
patches for all of them. GoboLinux provides a kernel patch for that.  
But I don't want to go there. It's a hack.

> OSX has the /System and /Library hierarchies that are familiar
> (enough)
> to mac users, and the only parts that are really hidden is all that
> UNIX
> stuff.
> 
> Maybe a gnome-vfs layer that interfaced with the packaging system
> would
> make things a bit easier for newbies? i.e. essentially a drag-and- 
> drop
> version of apt and dpkg?

My OS has no package manager except for updating the system folder. You  
install applications via drag&drop by means of relocatable application  
folders. And that's not in the planning stage. Consider it done.
 
> If you had a seperate hidden attribute (as well as the dot files
> convention) you'd have a lot of old-hat unix people not looking for
> such
> things, and when a 'ls -a' didn't show them, they'd assume they
> weren't
> there. Not good for security.

Frankly I don't care for "darkness is POSIX standard" dinosaurs.
I care for "enough tinkering already" OS X fugitives.
But you are right, ls -a should show those files. The "hidden"  
attribute should treat flagged files like dotfiles i.e. reveal them  
with ls -a. That's the way my ROX-Filer patch works at least on the GUI  
level.
And there is no need to hide files anywhere else than in / - to where  
btw. all volumes get mounted, the way BeOS did. I chose the BeOS  
directory layout over the NeXT layout. The Unix tree isn't hidden. Only  
the legacy symlinks are. The unix tree lives happily under
/boot/linux/system/posix, /boot/linux/etc and /boot/linux/var

Re: Will Reiser4 support a "hidden" attribute?

[Hans Reiser]

Nikita, please update us all on how far we have gotten in implementing this.

-- 
Hans

Re: Will Reiser4 support a "hidden" attribute?

[Nikita Danilov]

Hans Reiser writes:
 > Nikita, please update us all on how far we have gotten in implementing this.

OK.

We currently don't have ability to hide particular file. That is, there
is no way to somehow mark file hidden at the kernel level. If I am
allowed to humbly voice my opinion, usages shown by participants of this
thread (trimming down list of files visible in the GUI front-end) should
be done at the user level. In UNIX ls(1) command hides dot files for
ages.

On the other hand, some file system objects (pseudo files
http://namesys.com/v4/pseudo.html) are not shown by the readdir(2). But
this is to keep various utilities like cp(1) and friends from trying to
read from them.

 > 
 > -- 
 > Hans
 > 
 > 

Nikita.

Re: Will Reiser4 support a "hidden" attribute?

[Hans Reiser]

I respectfully disagree, and I expect us to keep to the plan I 
outlined.  Mr. Demidov, put this on your list of tasks to complete.

Guido, I am sorry to say that this will probably get added after we 
submit a reiser4 with fully debugged traditional functionality to Linus, 
which means sometime next year if I don't go broke in January.

Hans

Nikita Danilov wrote:

>Hans Reiser writes:
> > Nikita, please update us all on how far we have gotten in implementing this.
>
>OK.
>
>We currently don't have ability to hide particular file. That is, there
>is no way to somehow mark file hidden at the kernel level. If I am
>allowed to humbly voice my opinion, usages shown by participants of this
>thread (trimming down list of files visible in the GUI front-end) should
>be done at the user level. In UNIX ls(1) command hides dot files for
>ages.
>
>On the other hand, some file system objects (pseudo files
>http://namesys.com/v4/pseudo.html) are not shown by the readdir(2). But
>this is to keep various utilities like cp(1) and friends from trying to
>read from them.
>
> > 
> > -- 
> > Hans
> > 
> > 
>
>Nikita.
>
>
>  
>


-- 
Hans

Re: Will Reiser4 support a "hidden" attribute?

[Guido Schimmels]

Am 20.11.2003 19:49:39 schrieb(en) Nikita Danilov:
> Hans Reiser writes:
>  > Nikita, please update us all on how far we have gotten in
> implementing this.
> 
> OK.
> 
> We currently don't have ability to hide particular file. That is,
> there
> is no way to somehow mark file hidden at the kernel level. If I am
> allowed to humbly voice my opinion, usages shown by participants of
> this
> thread (trimming down list of files visible in the GUI front-end)
> should
> be done at the user level. In UNIX ls(1) command hides dot files for
> ages.

I have outlined why this is not an option. Handling this above the  
kernel/libc level means maintaining dozens of patches to consistently  
hide files throughout the GUI. And for Acrobat Reader e.g. you  would  
still need LD_PRELOAD trickery which means you are again down at the  
libc level. Thinking of it, an even better example is Sun's Java,  
which, though the sources are available, I'm not allowed to hack on.

Re: Will Reiser4 support a "hidden" attribute?

[Guido Schimmels]

Am 20.11.2003 15:23:53 schrieb(en) Guido Schimmels:

I forgot. To truely understand what the heck I'm talking about
look here (Alternative filesystem layout):
http://rox.sourceforge.net/phpwiki/index.php/Screenshots

I would like to add, despite appearance, what you are seeing complies  
to the LSB standard (as far as the FSH goes). Linux distros are already  
cluttered with compatibility symlinks. You'll find more of them on a  
SuSE system than on mine. 

Re: Will Reiser4 support a "hidden" attribute?

[Hubert Chan]

>>>>> "Stewart" == Stewart Smith <stewart@flamingspork.com> writes:

Stewart> On Thu, 2003-11-20 at 11:58, Guido Schimmels wrote:
>> Reiser4? This would be fantastic! I'm planning to use Reiser4 for my
>> Desktop Linux project. I need this feature to hide the Unix legacy
>> tree like MacOS X does it and (back then) BeOS.

Stewart> Note that MacOS X actually accomplishes this by the GUI having
Stewart> a list (inside a file named '.hidden') of things not to show.

[...]

Stewart> A patch to nautilus to do this would be pretty simple, although
Stewart> then you get into the problems of hiding a lot of stuff from
Stewart> the user (which you may not want to).

Nautilus 2.4 already does this.

-- 
Hubert Chan <hubert@uhoreg.ca> - http://www.uhoreg.ca/
PGP/GnuPG key: 1024D/124B61FA
Fingerprint: 96C5 012F 5F74 A5F7 1FF7  5291 AF29 C719 124B 61FA
Key available at wwwkeys.pgp.net.   Encrypted e-mail preferred.