V4 status

V4 status

[Fredrik Tolf]

May I ask what the current stability status is for V4? Is there mayhap
a HTTP resource for it that I have not found?

Fredrik Tolf

Re: V4 status

[David Masover]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Fredrik Tolf wrote:

>May I ask what the current stability status is for V4? Is there mayhap
>a HTTP resource for it that I have not found?
>
>Fredrik Tolf
>
>  
>

I believe patching your kernel will not hurt anything else, and mounting 
a filesystem will probably not hurt anything else.

I have a laptop on which I use Reiser4 for everything but /boot (as v4 
is not supported by grub and v3 was never supported very well).  It 
seems reasonably stable (once I fixed a problem with xscreensaver).  
However, I still back up daily, and will continue to do so until someone 
here tells me I can trust it.  (Then I'll fall back to no backup until I 
get the tape drive working so I can do proper incremental backups.)

BTW, to all -- I have had no problems specifically reiser4 related.  I 
was complaining of crashes earlier, but it seems those were either in my 
pam libs or my screensaver -- reinstalling all my software seemed to 
help (and as I didn't touch the kernel, it wouldn't have fixed it if it 
were a filesystem issue).  In fact, I know for sure it's at least partly 
due to problems with pam and related things, because my su (among other 
things) had lost its setuid bit -- due to my using the wrong arguments 
to cp when upgrading from v3.

The only thing I might complain about is that, although it was listed as 
a possibility to display file permissions as files within a file (for 
example, I should be able to do 'touch file; ls file'), I have had two 
problems there.  First, ls seems to know it's a file, and so I can't see 
any files within it.  Second, it needs the executable bit, or I get 
permission denied errors when trying to look at any files inside it.  
Third, even with ls not working, no guesses I've made on potential 
filenames has worked.

I know almost nothing about the interface behind this.  That said, 
here's what I'd suggest (without knowing any better):
- - If I look at something without using a trailing slash, it should be 
treated as a file, except maybe for compatibility reasons.
- - If I do use a trailing slash, or as a parent directory to anything, it 
should be treated as a directory.
- - If it is a regular file (and not a directory pretending to be a file 
through some odd plugin -- /etc/passwd could be a file constructed from 
files in /etc/passwd/) then permission to view it as a directory should 
be assumed for anyone with read access.  As an alternative, the ability 
to change into a directory could be implemented as another security 
attribute, which is automatically linked to executable permission for 
"normal" directories.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBP81HyAisZLIF6uqOAQIH9w/9HV/r2hZOGiUKUZjDsToFkNr+HJn+fTsj
C1imfdKC+tiL9kcI8wfjERFcwj/v6gMCmzXSs/XNRa12cs9Ddm+goeqHhfnjUiO8
FM0y6m7kebonM957VqJvVhxLfJkZvHjn3aCtHxl3oHfme9Xz7FrZbBpTbDTPA+aY
wYFFun51dQeIG6P4DqWNUIdEC9UNczdtk+Mhh9QsA9wCcT4bmO3UmiOs0mKN9o6K
KXsIJCE0DddXxKhROd0RnSY/jKz3KmpTtsNQDekXPaIvMa01qIQOvqv7bbQ/tux8
OZfYGb8dfR/8TmEIOg7HnrF5agcygpIe2EYb7bwmNi+iT8jA5l4NAOT5EdtzFZxk
+5hnX3vrSQezoRmr6cYnxgjZtlR5U/tcCZGLcPtvyL5KnxLE83uDBePfQZI8oXd2
mb4wcrLgmyw02n/m8yE7WMB5ukrj4YKNMIGxLR5u0nuNKJFHFLbqiIshg5ZQY1DF
CkWMHF1H18Qv6f6zszec4m47hkt/PKpSEArLzMoFA9ag/WtoNrDQq7+iRxy2LYKH
evK5AIMFAL9v3huxmCphHK6bjQzdTsl4mvnsPjB0hHcp+MhIsyBzobhd27oaBcsv
Hfj/0RywUwRlRj5zdwuoLuPHYlf38PjZlrAmfENWW2CrOL5+7RgbTGeUe+JU/J+t
+KlqxdjP1Dc=
=ExXE
-----END PGP SIGNATURE-----

Re: V4 status

[Redeeman]

On Wed, 2003-12-03 at 03:17, David Masover wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Fredrik Tolf wrote:
> 
> >May I ask what the current stability status is for V4? Is there mayhap
> >a HTTP resource for it that I have not found?
> >
> >Fredrik Tolf
> >
> >  
> >
> 
> I believe patching your kernel will not hurt anything else, and mounting 
> a filesystem will probably not hurt anything else.
> 
> I have a laptop on which I use Reiser4 for everything but /boot (as v4 
> is not supported by grub and v3 was never supported very well).  It 
reiserfs 3.6 works perfect in grub here
> seems reasonably stable (once I fixed a problem with xscreensaver).  
> However, I still back up daily, and will continue to do so until someone 
> here tells me I can trust it.  (Then I'll fall back to no backup until I 
> get the tape drive working so I can do proper incremental backups.)
> 
> BTW, to all -- I have had no problems specifically reiser4 related.  I 
> was complaining of crashes earlier, but it seems those were either in my 
> pam libs or my screensaver -- reinstalling all my software seemed to 
> help (and as I didn't touch the kernel, it wouldn't have fixed it if it 
> were a filesystem issue).  In fact, I know for sure it's at least partly 
> due to problems with pam and related things, because my su (among other 
> things) had lost its setuid bit -- due to my using the wrong arguments 
> to cp when upgrading from v3.
> 
> The only thing I might complain about is that, although it was listed as 
> a possibility to display file permissions as files within a file (for 
> example, I should be able to do 'touch file; ls file'), I have had two 
> problems there.  First, ls seems to know it's a file, and so I can't see 
> any files within it.  Second, it needs the executable bit, or I get 
> permission denied errors when trying to look at any files inside it.  
> Third, even with ls not working, no guesses I've made on potential 
> filenames has worked.
> 
> I know almost nothing about the interface behind this.  That said, 
> here's what I'd suggest (without knowing any better):
> - - If I look at something without using a trailing slash, it should be 
> treated as a file, except maybe for compatibility reasons.
> - - If I do use a trailing slash, or as a parent directory to anything, it 
> should be treated as a directory.
> - - If it is a regular file (and not a directory pretending to be a file 
> through some odd plugin -- /etc/passwd could be a file constructed from 
> files in /etc/passwd/) then permission to view it as a directory should 
> be assumed for anyone with read access.  As an alternative, the ability 
> to change into a directory could be implemented as another security 
> attribute, which is automatically linked to executable permission for 
> "normal" directories.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.3 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
> 
> iQIVAwUBP81HyAisZLIF6uqOAQIH9w/9HV/r2hZOGiUKUZjDsToFkNr+HJn+fTsj
> C1imfdKC+tiL9kcI8wfjERFcwj/v6gMCmzXSs/XNRa12cs9Ddm+goeqHhfnjUiO8
> FM0y6m7kebonM957VqJvVhxLfJkZvHjn3aCtHxl3oHfme9Xz7FrZbBpTbDTPA+aY
> wYFFun51dQeIG6P4DqWNUIdEC9UNczdtk+Mhh9QsA9wCcT4bmO3UmiOs0mKN9o6K
> KXsIJCE0DddXxKhROd0RnSY/jKz3KmpTtsNQDekXPaIvMa01qIQOvqv7bbQ/tux8
> OZfYGb8dfR/8TmEIOg7HnrF5agcygpIe2EYb7bwmNi+iT8jA5l4NAOT5EdtzFZxk
> +5hnX3vrSQezoRmr6cYnxgjZtlR5U/tcCZGLcPtvyL5KnxLE83uDBePfQZI8oXd2
> mb4wcrLgmyw02n/m8yE7WMB5ukrj4YKNMIGxLR5u0nuNKJFHFLbqiIshg5ZQY1DF
> CkWMHF1H18Qv6f6zszec4m47hkt/PKpSEArLzMoFA9ag/WtoNrDQq7+iRxy2LYKH
> evK5AIMFAL9v3huxmCphHK6bjQzdTsl4mvnsPjB0hHcp+MhIsyBzobhd27oaBcsv
> Hfj/0RywUwRlRj5zdwuoLuPHYlf38PjZlrAmfENWW2CrOL5+7RgbTGeUe+JU/J+t
> +KlqxdjP1Dc=
> =ExXE
> -----END PGP SIGNATURE-----
-- 
Regards, Redeeman
()  ascii ribbon campaign - against html e-mail 
/\                        - against microsoft attachments

grub (Re: V4 status)

[David Masover]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>
> >reiserfs 3.6 works perfect in grub here

It may have worked for me, with notail, but I have heard too many 
stories.  Anyway, /boot is 5-10 megs, usually not mounted, so I see no 
performance loss using ext3 there.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBP86MxgisZLIF6uqOAQLc2xAAgCp7HIDmsWiHW2PHS8aXT/TzzJQjbExP
u+xZZNlmOYPZ+Klzj6CTjuWnC16GbG/TqKtAl5jQ0AIGNKoydPpcHGXFhyQCBbPU
aan0/WWR1QLV75EIL5x3R5kgO6jI2AHlxcDpRlvKJIdS3Q8iw/KB3L6nO/xqgba4
C0SJg8WPvgGtC/JGOaU8JvIbVeasHogY+HH0HZ6zWuFEckGGjoTiQj7yTDFdCKBg
JtsWS7jJ24KdFR0NMOJQTJOOM8z9n9gOIHod5rzP8g7tSprZunJOZsSq8E3pLd5m
wSebBC09VYuND6byxyI/HfywVehg+Xx0lbpr6LH3gjp8jg+oR3uO6SoSpsWPEmWP
3B5Ruivlp1EDMWjDIDUjanwroIRR0Yv3efGwORYUFnxQMGNy6HLmazgJ66lsA9Vq
e/bMIDflf6Gp86aH+gTlSOVfc/H23gzjWsz6VdpUvYoZe7PxtEipw6Wokx+v1gS1
imR3/qgHkPmltN+RkSNU0+SjTxKQsSuX++DmQ1j3/VW0mARIwdz4UGi+xNzHH7AC
HXat5yqlzRJexgYVjXFs+ptdG6aPpoStR3hiTGCTZgAscWxE6pb/vrlCYt+WTQFR
w1mVufQVpQ0ZYEsYYw5s8//igMapxmm4JpbCebxyV+sPORBnBDPmKsNBH8639QlG
onUku5zQmjY=
=p/Gi
-----END PGP SIGNATURE-----

Re: V4 status

[Hans Reiser]

We are still able to crash reiser4.  It has been 1 month from being 
debugged for a very long time now....  Sigh.  Vs is working on nfs file 
handle encoding and decoding.  We need to release a snapshot again 
sometime reasonably soon....

Hans

David Masover wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Fredrik Tolf wrote:
>
>> May I ask what the current stability status is for V4? Is there mayhap
>> a HTTP resource for it that I have not found?
>>
>> Fredrik Tolf
>>
>>  
>>
>
> I believe patching your kernel will not hurt anything else, and 
> mounting a filesystem will probably not hurt anything else.
>
> I have a laptop on which I use Reiser4 for everything but /boot (as v4 
> is not supported by grub and v3 was never supported very well).  It 
> seems reasonably stable (once I fixed a problem with xscreensaver).  
> However, I still back up daily, and will continue to do so until 
> someone here tells me I can trust it.  (Then I'll fall back to no 
> backup until I get the tape drive working so I can do proper 
> incremental backups.)
>
> BTW, to all -- I have had no problems specifically reiser4 related.  I 
> was complaining of crashes earlier, but it seems those were either in 
> my pam libs or my screensaver -- reinstalling all my software seemed 
> to help (and as I didn't touch the kernel, it wouldn't have fixed it 
> if it were a filesystem issue).  In fact, I know for sure it's at 
> least partly due to problems with pam and related things, because my 
> su (among other things) had lost its setuid bit -- due to my using the 
> wrong arguments to cp when upgrading from v3.
>
> The only thing I might complain about is that, although it was listed 
> as a possibility to display file permissions as files within a file 
> (for example, I should be able to do 'touch file; ls file'), I have 
> had two problems there.  First, ls seems to know it's a file, and so I 
> can't see any files within it.  Second, it needs the executable bit, 
> or I get permission denied errors when trying to look at any files 
> inside it.  Third, even with ls not working, no guesses I've made on 
> potential filenames has worked.
>
> I know almost nothing about the interface behind this.  That said, 
> here's what I'd suggest (without knowing any better):
> - - If I look at something without using a trailing slash, it should 
> be treated as a file, except maybe for compatibility reasons.
> - - If I do use a trailing slash, or as a parent directory to 
> anything, it should be treated as a directory.
> - - If it is a regular file (and not a directory pretending to be a 
> file through some odd plugin -- /etc/passwd could be a file 
> constructed from files in /etc/passwd/) then permission to view it as 
> a directory should be assumed for anyone with read access.  As an 
> alternative, the ability to change into a directory could be 
> implemented as another security attribute, which is automatically 
> linked to executable permission for "normal" directories.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.3 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
> iQIVAwUBP81HyAisZLIF6uqOAQIH9w/9HV/r2hZOGiUKUZjDsToFkNr+HJn+fTsj
> C1imfdKC+tiL9kcI8wfjERFcwj/v6gMCmzXSs/XNRa12cs9Ddm+goeqHhfnjUiO8
> FM0y6m7kebonM957VqJvVhxLfJkZvHjn3aCtHxl3oHfme9Xz7FrZbBpTbDTPA+aY
> wYFFun51dQeIG6P4DqWNUIdEC9UNczdtk+Mhh9QsA9wCcT4bmO3UmiOs0mKN9o6K
> KXsIJCE0DddXxKhROd0RnSY/jKz3KmpTtsNQDekXPaIvMa01qIQOvqv7bbQ/tux8
> OZfYGb8dfR/8TmEIOg7HnrF5agcygpIe2EYb7bwmNi+iT8jA5l4NAOT5EdtzFZxk
> +5hnX3vrSQezoRmr6cYnxgjZtlR5U/tcCZGLcPtvyL5KnxLE83uDBePfQZI8oXd2
> mb4wcrLgmyw02n/m8yE7WMB5ukrj4YKNMIGxLR5u0nuNKJFHFLbqiIshg5ZQY1DF
> CkWMHF1H18Qv6f6zszec4m47hkt/PKpSEArLzMoFA9ag/WtoNrDQq7+iRxy2LYKH
> evK5AIMFAL9v3huxmCphHK6bjQzdTsl4mvnsPjB0hHcp+MhIsyBzobhd27oaBcsv
> Hfj/0RywUwRlRj5zdwuoLuPHYlf38PjZlrAmfENWW2CrOL5+7RgbTGeUe+JU/J+t
> +KlqxdjP1Dc=
> =ExXE
> -----END PGP SIGNATURE-----
>
>
>


-- 
Hans

Re: V4 status

[Hans Reiser]

David Masover wrote:

>
>
> The only thing I might complain about is that, although it was listed 
> as a possibility to display file permissions as files within a file 
> (for example, I should be able to do 'touch file; ls file'), I have 
> had two problems there.  First, ls seems to know it's a file, and so I 
> can't see any files within it.  Second, it needs the executable bit, 
> or I get permission denied errors when trying to look at any files 
> inside it.  Third, even with ls not working, no guesses I've made on 
> potential filenames has worked.

Nikita will comment on the state of this code, and your remarks below.

>
> I know almost nothing about the interface behind this.  That said, 
> here's what I'd suggest (without knowing any better):
> - - If I look at something without using a trailing slash, it should 
> be treated as a file, except maybe for compatibility reasons.
> - - If I do use a trailing slash, or as a parent directory to 
> anything, it should be treated as a directory.
> - - If it is a regular file (and not a directory pretending to be a 
> file through some odd plugin -- /etc/passwd could be a file 
> constructed from files in /etc/passwd/) then permission to view it as 
> a directory should be assumed for anyone with read access.  As an 
> alternative, the ability to change into a directory could be 
> implemented as another security attribute, which is automatically 
> linked to executable permission for "normal" directories.
>
>
>
>


-- 
Hans

Re: V4 status

[Nikita Danilov]

Hans Reiser writes:
 > David Masover wrote:
 > 
 > >
 > >
 > > The only thing I might complain about is that, although it was listed 
 > > as a possibility to display file permissions as files within a file 
 > > (for example, I should be able to do 'touch file; ls file'), I have 
 > > had two problems there.  First, ls seems to know it's a file, and so I 
 > > can't see any files within it.  Second, it needs the executable bit, 
 > > or I get permission denied errors when trying to look at any files 
 > > inside it.  Third, even with ls not working, no guesses I've made on 
 > > potential filenames has worked.

$ chmod u+x foo
$ cat foo/..pseudo

or, take a look at http://namesys.com/v4/pseudo.html

 > 
 > Nikita will comment on the state of this code, and your remarks below.
 > 
 > >
 > > I know almost nothing about the interface behind this.  That said, 
 > > here's what I'd suggest (without knowing any better):
 > > - - If I look at something without using a trailing slash, it should 
 > > be treated as a file, except maybe for compatibility reasons.
 > > - - If I do use a trailing slash, or as a parent directory to 
 > > anything, it should be treated as a directory.
 > > - - If it is a regular file (and not a directory pretending to be a 
 > > file through some odd plugin -- /etc/passwd could be a file 
 > > constructed from files in /etc/passwd/) then permission to view it as 
 > > a directory should be assumed for anyone with read access.  As an 
 > > alternative, the ability to change into a directory could be 
 > > implemented as another security attribute, which is automatically 
 > > linked to executable permission for "normal" directories.
 > >

That's unfortunately very hard to do if you are using usual system calls
(like readdir(2), or open(2)), because they are tunneled through VFS
that enforces some semantics.

Another problem ("ls seems to know it's a file") is with user level
programs that are sometimes too smart.

 > >
 > >
 > >
 > 
 > 
 > -- 
 > Hans
 > 
 > 

Nikita.

pseudo files (Re: V4 status)

[David Masover]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

cool, thanks.

>That's unfortunately very hard to do if you are using usual system calls
>(like readdir(2), or open(2)), because they are tunneled through VFS
>that enforces some semantics.
>  
>
Enforces as in, if I enter the name of a directory, it adds a / to it 
before it passes to the filesystem?
I know it doesn't chop off trailing slashes (except in Reiser4, for 
obvious reasons).
Or, as this has a serious potential for becoming offtopic, can you point 
me to some reading material?

>Another problem ("ls seems to know it's a file") is with user level
>programs that are sometimes too smart.
>  
>
Maybe I'll try to fix that.  Intelligence seems to be the easiest thing 
to remove from a program.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBP86O6gisZLIF6uqOAQKepQ//Vl/JRzKc7NkzWDi1KuIjR6D5/tljQlOD
O3ZYhv42Ugfk3J+HEF61ObeahPUqjpBXiEV9WKKp/m39EmdF3xyO7FvfiUwtwOVG
yLvhz/dE8WaUD4MQPVO/E0qZ+/cVb0qzfuBBdeGrTgfb/2F3oUIkiWjI7ftkpfaZ
spljQljQgO5fyvkaTYsjJ30hEJKBUHcYyMQ101FuSKOpuV0ZSrHIGlYaVC+8TJMl
DKdx0rfkoBAFEtgwkeoigYslBUurfJbscHLNVMIlsI3rhufIJ5sn3OEyl8animI0
XFG6ljDATMnGYYy2g7pat226a2l9skzEsMtcCH/XrWweX17QRCgZdOZSkzKosaXX
paeX4Qn0l64Q4eH4mc5p8Rsx1qWe/pQW8wZouCrgfwaZl2dMxHJtFZNxGVcp+A9/
nHVXRv24mLIQ1jAIMIk+O8so/YQTvFEHbu18BxgTKPNuDsyKPDgr0EguTwHf907w
tGMi931qtaoLuPXSE38/e0et5r9+fOLB9lE+uUNmV6xxFtNh3dMlStbdzuZ8wfYa
cd5sTq9F7Irm7TPxRBd7TTjREEcQYfhyZelmkuZI9eA7aU4WD6RDYziGp87mmevD
NjHzD6D1lKJGX8NW84Nxh/KP8N93LceG6282u9krYxQAY7x47L9AgGsRG/g8zfyw
0+qY2yoVngE=
=bdb/
-----END PGP SIGNATURE-----

Re: V4 status

[Enrique Perez-Terron]

On Wed, 2003-12-03 at 20:40, Nikita Danilov wrote:
...
>  > > (for example, I should be able to do 'touch file; ls file'), I have 
>  > > had two problems there.  First, ls seems to know it's a file, and so I 
>  > > can't see any files within it.  Second, it needs the executable bit, 
... 
> Another problem ("ls seems to know it's a file") is with user level
> programs that are sometimes too smart.

What happens on v4 if you do "ls -l file/." ?

Regards, Enrique

pseudo files & execute bit (Re: V4 status)

[David Masover]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Enrique Perez-Terron wrote:

>On Wed, 2003-12-03 at 20:40, Nikita Danilov wrote:
>...
>  
>
>> > > (for example, I should be able to do 'touch file; ls file'), I have 
>> > > had two problems there.  First, ls seems to know it's a file, and so I 
>> > > can't see any files within it.  Second, it needs the executable bit, 
>>    
>>
>... 
>  
>
>>Another problem ("ls seems to know it's a file") is with user level
>>programs that are sometimes too smart.
>>    
>>
>
>What happens on v4 if you do "ls -l file/." ?
>
>  
>
The same thing as if I do "ls -l file" (with the addition of a . on the 
end) anywhere else, if file has execute permission.  The problem is ls 
checks the file first and notices it's a file, and then refuses to try 
it as a directory.  The only way around this is to fool it -- ls works 
on file/..plugin, because that looks like a normal directory.

How about this:  some patch (or mount option) to VFS that would have 
directories be fully readable (as if there was an execute bit) if only 
the read bit is set?  This would definitely be backward-compatable with 
current filesystems, although to avoid some unnecessary ugliness there's 
a lot of programs that would need to be patched.

It would help if something could be fixed in Reiser4 (or VFS) to allow a 
file to appear as a directory.  I mean appear as one, so that ls works 
properly without needing to be patched.  Obviously lots of things are 
(hopefully) going to be patched to support Reiser4, and if this "remove 
execute bit from dirs" idea flies, I might be breaking, say, POSIX, as 
well as forcing most programs to be patched.

The reason I'm thinking this way is that I could easily see a use for 
(even if I have no idea how it'd work) a plugin on a directory to allow 
it to be read as a file.  The idea is to create drop-in replacements for 
current single files like /etc/passwd.  Say /etc/passwd is a directory, 
and inside that directory are numerous files, each with its own idea 
about the password file.  Reading from the directory as a file functions 
just as /etc/passwd, probably composing (maybe caching) the file out of 
its composite pieces.  Things like this are done all the time in a less 
clean fashion -- on my system, /etc/modules.conf is automatically 
generated from files in /etc/modules.d.  That works, it's just ugly, and 
not as automatic as it could be -- I have to type 'update-modules' to 
regenerate the file.

It would not make sense for /etc/passwd to be executable, but it would 
not make sense for /etc/modules.d to be unreadable.

Obviously there would be times when you want smaller objects attached to 
a normal file, like the permission plugin.  In the cases I've given, 
that may be a bad idea -- for example, we're told not to edit 
modules.conf directly.  It would be much nicer to have it be an fs 
plugin that doesn't support writing (but does cache itself), and maybe 
even strip things like comments in the process (since those would reside 
in the child dir).  This looks much cleaner to implement as a directory.

I'm sure it can be done with the pseudo-files I've seen, like linking 
/etc/passwd.d/..passwd to /etc/passwd, but I still think that's messy.

If I sound like I'm rambling, tell me -- maybe it's time for me to 
actually read the source.
"The power of the One extends beyond the Matrix, all the way to the 
Source..."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBP9AAhgisZLIF6uqOAQK+Qw/+KeKNKcJCDqRIwgIsciyTq/pTHa93QMKA
FNrRMEzTC21wuyuECLzHR2BzvLIEHKbStt9MeHjqFbZOjd5EIWwCMfyzBMZqwdUe
1FFNwnOox8r/JogW4hzIQ0FvInQRmIVbdYdlLGem2ocfdSj7KvKhaJBTqNDNy49Q
7V/YTUZsldeik3a3AFzJyqok21BGLng2Je0czQigFEp2jGNzz/REO+IvUSc9ZCPa
RtHMBfgRP08U9CJAKXhN/DS0pP1LY9cHL+IeM25XSxFJM9sypCzck/VPn5tnxnGv
+M0c9FqdhB1Jd+bKyw2IoZsyjozGdrPAsNVRgR9Xh6+xY71M7tsOJ25TpoAXhQ31
ZGcNBGsBV5YmMM3gGZAf2nAOgpNPHzdOZ8qKHOuSrWfVCaknWnumhxLO9XnNqg9G
FBVIeFNbz3vAA082hpwb3V+X4McWFZfKawvud+sY+sKLiM7EHx917/hMDtZ4gjUN
afd4Bx0M0+rHg2oCyTCDZMeIscYx/9sDWb/xvnh3ZlG/U8E5+J5zAIKDewh8pyAz
PXLKmpZ+cVjBJjzQdon8JZNjMFi63uI3IS1KuUU4jNPmkzHQNEzY8NA3uqwD0w3K
4ukQpUu9MwOmec+xZkMCxij5cVcR8InmKFi6KtokkPO6b6jlcB6XUR3nHUkNvj0v
5fozwcB5mEM=
=yFiU
-----END PGP SIGNATURE-----

The x Bit Problem

[Grant Miner]

An interesting thing I discovered is that Windows simply ignores the 'x' 
bit (I should say the Windows equivalent of the 'x' bit, called 
"traverse folder / execute file"), but there is a policy setting that 
overrides this attribute.

I know users get tripped up on this a lot in Unix, like when they don't 
understand why the webserver can't read their public_html directory.  It 
might be a good option for Linux.

Re: The x Bit Problem

[Bob]

Grant Miner wrote:

> An interesting thing I discovered is that Windows simply ignores the 
> 'x' bit (I should say the Windows equivalent of the 'x' bit, called 
> "traverse folder / execute file"), but there is a policy setting that 
> overrides this attribute.
>
> I know users get tripped up on this a lot in Unix, like when they 
> don't understand why the webserver can't read their public_html 
> directory.  It might be a good option for Linux.
>
> -
> To unsubscribe from this list: send the line "unsubscribe 
> linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
Windows doesn't just ignore it. When I move
files from win to linux all the x bits are turned
on so txt and bz2 and jpg files are marked
executable. That's annoying and a security
risk.

-Bob

Re: The x Bit Problem

[Tomasz Rola]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 5 Dec 2003, Bob wrote:

> Windows doesn't just ignore it. When I move
> files from win to linux all the x bits are turned
> on so txt and bz2 and jpg files are marked
> executable. That's annoying and a security
> risk.

I'm jumping into this thread so this might have already been told but how
about umask=0111 mount option for dos (fat,vfat etc) filesystems? Also,
one may mount nodev, noexec and nosuid when appropriate. This, of course,
is not remedy, just a little painkiller.

bye
T.

- --
** A C programmer asked whether computer had Buddha's nature.      **
** As the answer, master did "rm -rif" on the programmer's home    **
** directory. And then the C programmer became enlightened...      **
**                                                                 **
** Tomasz Rola          mailto:tomasz_rola@bigfoot.com             **


-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
Charset: noconv

iQA/AwUBP9B6dRETUsyL9vbiEQKUaACgwt2yOk6vtNZxfs5y2volDhvnoXkAoK+X
jfyT78ztYklvsTt2SOKCaEaU
=TJm7
-----END PGP SIGNATURE-----

Re: The x Bit Problem

[Tomasz Rola]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 5 Dec 2003, Tomasz Rola wrote:

> On Fri, 5 Dec 2003, Bob wrote:
> 
> > Windows doesn't just ignore it. When I move
> > files from win to linux all the x bits are turned
> > on so txt and bz2 and jpg files are marked
> > executable. That's annoying and a security
> > risk.
> 
> I'm jumping into this thread so this might have already been told but how
> about umask=0111 mount option for dos (fat,vfat etc) filesystems? Also,

And I'm answering to myself.

Nope. But with showexec=no it seems that only dirs and *.exe are x-ed.
Writing faster than light isn't good because humans think slower than
light...

bye
T.

- --
** A C programmer asked whether computer had Buddha's nature.      **
** As the answer, master did "rm -rif" on the programmer's home    **
** directory. And then the C programmer became enlightened...      **
**                                                                 **
** Tomasz Rola          mailto:tomasz_rola@bigfoot.com             **


-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
Charset: noconv

iQA/AwUBP9CQaRETUsyL9vbiEQKkqACcCpWkZIqg2eFKCaHkCrQdKvLIRS8Anixh
8Lzl3FOsuEgy9FvFS0lPoqLI
=rTu8
-----END PGP SIGNATURE-----

Re: The x Bit Problem

[Hans Reiser]

Grant Miner wrote:

> An interesting thing I discovered is that Windows simply ignores the 
> 'x' bit (I should say the Windows equivalent of the 'x' bit, called 
> "traverse folder / execute file"), but there is a policy setting that 
> overrides this attribute.
>
> I know users get tripped up on this a lot in Unix, like when they 
> don't understand why the webserver can't read their public_html 
> directory.  It might be a good option for Linux.
>
>
>
The right solution is to have a separate readdir permission, so that a 
file-directory can be not executable but be listable, and vice-versa.  
The problem comes from overloading the bit and also changing whether 
objects can be simultaneously files and directories.

-- 
Hans

Re: The x Bit Problem

[David Masover]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hans Reiser wrote:

> Grant Miner wrote:
>
>> An interesting thing I discovered is that Windows simply ignores the 
>> 'x' bit (I should say the Windows equivalent of the 'x' bit, called 
>> "traverse folder / execute file"), but there is a policy setting that 
>> overrides this attribute.
>>
>> I know users get tripped up on this a lot in Unix, like when they 
>> don't understand why the webserver can't read their public_html 
>> directory.  It might be a good option for Linux.
>>
>>
>>
> The right solution is to have a separate readdir permission, so that a 
> file-directory can be not executable but be listable, and vice-versa.  
> The problem comes from overloading the bit and also changing whether 
> objects can be simultaneously files and directories.
>
Why does that need to be separate from the read bit?  In fact, right 
now, I can actually get a directory listing, but I can't even find out a 
single attribute about the files inside if the execute bit is not set.  
When is this desireable?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBP9CQIwisZLIF6uqOAQLdPw/9HEHbi41hey1LoH8d2wuQRDTUwH5iEZVN
ld/pnuPlHPp1sO8ag+WjoT4sv3umlSBPdRtzk3H1Y8WSBZ4xgnD6imo9eAQXzMmu
UG4t9reWrCeKgl95KCJmapH6PPYFE6O8+YliBO4uCEFHLX6UM0Xb02nkZ2dQ25+G
E1ryv5KUI+lMSliTuOEzfmMzuXapRul59Cc6WPplDmXN9ApMEnxJKYQtCBeYX1kf
Wr4/6eGnJ91kIIfMGqe30IgOBbHRAENIq+K/ha+aUjmCQOwFjEaU1Imd3ytFZbPn
xxwzXoD9+C2kNh6l3LFKiAm43rssTBwohSZbp8DNbhvboGOCgNuzzE6YzyJFNcCl
hmW4PBoKP+SG6lrGb0C3USyjY/7U8KY1OHAviNyZW2InfFpbsfNhQg/FIH2eFOHS
uhnVborliZwUA1XGxDZPG2pvrm3e0dTHyCLu2FENU7ErY/3o5IBoTS2RypWMkjiK
PBLvedufBMO4Ssq8vZg+t74pLaESsMvw4J6ebr8YwakJQS2A/a6mDTOLIe11qZby
suH35Cu3RW6ecxJ6WQnmDQcozcbKdybwbf3KWjn+MppMtzPpF+MwllykMKCHYf4t
5bVM8Mc1y1zBB+zYmF0Kv0rP9CtOvOmri2O6tDXtUOI/qDNDqKB5u5ICn/q5WVmF
Y7QciJdsWvA=
=jZ2A
-----END PGP SIGNATURE-----