"Albert D. Cahalan" <[EMAIL PROTECTED]> writes:
> Doug writes:
> > bash-2.03$ cd /tmp
> > bash-2.03$ cat >foo
> > This is a test.
> > bash-2.03$ chmod u-r foo
>
> No, you zeroed the owner's read bit. When the bit isn't
> implemented it must be always set.
>
> By "(owner may read own files)" I
Doug writes:
> "Albert D. Cahalan" <[EMAIL PROTECTED]> writes:
>> If you need to steal a bit, grab one that won't hurt.
>> Take the owner's read bit. (owner may read own files)
>
> Er,
>
> bash-2.03$ cd /tmp
> bash-2.03$ cat >foo
> This is a test.
> bash-2.03$ chmod u-r foo
No, you zeroed the
"Albert D. Cahalan" <[EMAIL PROTECTED]> writes:
> Shane Nay writes:
>
> > but the bits are useless in the "normal interpretation" of it,
> ...
> > But then you pull out the write bits,
>
> If you need to steal a bit, grab one that won't hurt.
> Take the owner's read bit. (owner may read own
Shane Nay writes:
> but the bits are useless in the "normal interpretation" of it,
...
> But then you pull out the write bits,
If you need to steal a bit, grab one that won't hurt.
Take the owner's read bit. (owner may read own files)
-
To unsubscribe from this list: send the line "unsubscribe
Shane Nay writes:
but the bits are useless in the "normal interpretation" of it,
...
But then you pull out the write bits,
If you need to steal a bit, grab one that won't hurt.
Take the owner's read bit. (owner may read own files)
-
To unsubscribe from this list: send the line "unsubscribe
"Albert D. Cahalan" [EMAIL PROTECTED] writes:
Shane Nay writes:
but the bits are useless in the "normal interpretation" of it,
...
But then you pull out the write bits,
If you need to steal a bit, grab one that won't hurt.
Take the owner's read bit. (owner may read own files)
Er,
Doug writes:
"Albert D. Cahalan" [EMAIL PROTECTED] writes:
If you need to steal a bit, grab one that won't hurt.
Take the owner's read bit. (owner may read own files)
Er,
bash-2.03$ cd /tmp
bash-2.03$ cat foo
This is a test.
bash-2.03$ chmod u-r foo
No, you zeroed the owner's read
"Albert D. Cahalan" [EMAIL PROTECTED] writes:
Doug writes:
bash-2.03$ cd /tmp
bash-2.03$ cat foo
This is a test.
bash-2.03$ chmod u-r foo
No, you zeroed the owner's read bit. When the bit isn't
implemented it must be always set.
By "(owner may read own files)" I refer to what
On Tue, 9 Jan 2001, Rusty Russell wrote:
> In message <[EMAIL PROTECTED]> you
> write:
> > I've been thinking of doing a cramfs2, and the only thing I'd change is
> > (a) slightly bigger blocksize (maybe 8k or 16k) and (b) re-order the
> > meta-data and the real data so that I could easily
In message <[EMAIL PROTECTED]> you
write:
> I've been thinking of doing a cramfs2, and the only thing I'd change is
> (a) slightly bigger blocksize (maybe 8k or 16k) and (b) re-order the
> meta-data and the real data so that I could easily compress the metadata
> too. cramfs doesn't have any
On Mon, 8 Jan 2001, Ingo Oeser wrote:
> On Mon, Jan 08, 2001 at 12:13:39PM +, Shane Nay wrote:
> > This may not initially seem like such a great thing..., but imagine a base
> > distro being distributed as a cramfs file. Copy the thing over to your HD
> > and you're done, otherwise the
On Mon, 8 Jan 2001, Ingo Oeser wrote:
>
> cramfs is a read-only fs. So we should honour that in inode->mode to
> avoid confusion of programs.
No no no. This breaks device nodes etc quite badly.
A change to mkcramfs might be fine - but it has to conditionalize on the
file being a regular
On Mon, Jan 08, 2001 at 08:42:35AM -0500, Alexander Viro wrote:
> If program considers these bits of st_mode as indication of ability
> to write into file - program is buggy and should be fixed. Regardless
> of cramfs.
Ok, point taken.
I fixed the generation of the tree to be crammed into the
Ingo,
> You can use (GNU-)tar for this. It even keeps track of other bits like
> ext2fs attributes, AFAIK.
True..., but cramfs is acting like a mountable (tar czvf) because of the
compressed pages. Seems redundant to have a tar on top of what is basically
a segmented tar with frontal
On Mon, 8 Jan 2001, Ingo Oeser wrote:
> Then we might need W bits, but currently they disturb things like
> "test" and the perl equivalent, which is quite annoying and
> complexifies code. (Yes, I'm selfish too ;-))
Huh??? Consider write-protected floppy. What, you mean that it also
should
On Mon, Jan 08, 2001 at 12:13:39PM +, Shane Nay wrote:
> This may not initially seem like such a great thing..., but imagine a base
> distro being distributed as a cramfs file. Copy the thing over to your HD
> and you're done, otherwise the distro packaging has to keep track of
>
Ingo,
> cramfs is a read-only fs. So we should honour that in inode->mode
> to avoid confusion of programs.
>
> My isofs shows this too, so I think I'm right deleting the write
> permissions in the inode. May be we should change it in
> mkcramfs (too).
>
> I don't know what POSIX says about RO
Hi Linus,
hi all,
cramfs is a read-only fs. So we should honour that in inode->mode
to avoid confusion of programs.
My isofs shows this too, so I think I'm right deleting the write
permissions in the inode. May be we should change it in
mkcramfs (too).
I don't know what POSIX says about RO fs,
Hi Linus,
hi all,
cramfs is a read-only fs. So we should honour that in inode-mode
to avoid confusion of programs.
My isofs shows this too, so I think I'm right deleting the write
permissions in the inode. May be we should change it in
mkcramfs (too).
I don't know what POSIX says about RO fs,
Ingo,
cramfs is a read-only fs. So we should honour that in inode-mode
to avoid confusion of programs.
My isofs shows this too, so I think I'm right deleting the write
permissions in the inode. May be we should change it in
mkcramfs (too).
I don't know what POSIX says about RO fs, but I
On Mon, Jan 08, 2001 at 12:13:39PM +, Shane Nay wrote:
This may not initially seem like such a great thing..., but imagine a base
distro being distributed as a cramfs file. Copy the thing over to your HD
and you're done, otherwise the distro packaging has to keep track of
permisions
On Mon, 8 Jan 2001, Ingo Oeser wrote:
Then we might need W bits, but currently they disturb things like
"test" and the perl equivalent, which is quite annoying and
complexifies code. (Yes, I'm selfish too ;-))
Huh??? Consider write-protected floppy. What, you mean that it also
should
Ingo,
You can use (GNU-)tar for this. It even keeps track of other bits like
ext2fs attributes, AFAIK.
True..., but cramfs is acting like a mountable (tar czvf) because of the
compressed pages. Seems redundant to have a tar on top of what is basically
a segmented tar with frontal indexing
On Mon, Jan 08, 2001 at 08:42:35AM -0500, Alexander Viro wrote:
If program considers these bits of st_mode as indication of ability
to write into file - program is buggy and should be fixed. Regardless
of cramfs.
Ok, point taken.
I fixed the generation of the tree to be crammed into the
On Mon, 8 Jan 2001, Ingo Oeser wrote:
cramfs is a read-only fs. So we should honour that in inode-mode to
avoid confusion of programs.
No no no. This breaks device nodes etc quite badly.
A change to mkcramfs might be fine - but it has to conditionalize on the
file being a regular file.
On Mon, 8 Jan 2001, Ingo Oeser wrote:
On Mon, Jan 08, 2001 at 12:13:39PM +, Shane Nay wrote:
This may not initially seem like such a great thing..., but imagine a base
distro being distributed as a cramfs file. Copy the thing over to your HD
and you're done, otherwise the distro
In message [EMAIL PROTECTED] you
write:
I've been thinking of doing a cramfs2, and the only thing I'd change is
(a) slightly bigger blocksize (maybe 8k or 16k) and (b) re-order the
meta-data and the real data so that I could easily compress the metadata
too. cramfs doesn't have any
On Tue, 9 Jan 2001, Rusty Russell wrote:
In message [EMAIL PROTECTED] you
write:
I've been thinking of doing a cramfs2, and the only thing I'd change is
(a) slightly bigger blocksize (maybe 8k or 16k) and (b) re-order the
meta-data and the real data so that I could easily compress the
28 matches
Mail list logo
