🚀 go-pugleaf

In article <40njuk$388@sundog.tiac.net>,
Robert Krawitz <rlk@laraby.tiac.net> wrote:

>The more widespread a particular encryption technology is, the more
>vulnerable to attack.  This should be part of the driver for a
>particular class of filesystem.

Not true. The more widespread a particular encryption technology is,
the more people have a chance to poke holes in it, and the more
chance you have of finding out about a weakness before you are
affected by it.

One of the reasons you can trust PGP is that the source code is
freely and widely distributed, and is the subject of scrutiny by
encryption experts.

If one-time pads became a "widespread encryption technology",
would you lose confidence in them?
-- 
Finger c2a192@keats.ugrad.cs.ubc.ca for PGP public key. Or contact
one of the public key servers -- the key id is 0xD3C7995D.

Robert Krawitz (rlk@laraby.tiac.net) wrote:

>    >:    -long file name support

> ...like unlimited (at least the filesystem switch shouldn't impose a
> limit).

Yes, and in the AOL-esque sense, I can just image a file name that spans 
five screens full of path and name, just to contain a "Me too" as the data.

How would one store, and iterate a filesystem where filenames could be 
any size? Would one open a system file called "Directory", and use a 
system-supplied database utility to iterate the files?

Far better would be a (say) 1024 limit on the total path size. So from 
the root directory to the end of the filename would total not more than 
1024 chars.

In article <412c9o$ll3@inca01.inca.co.nz>, gmiller@inca.co.nz (Gaven
Miller) wrote:

> Robert Krawitz (rlk@laraby.tiac.net) wrote:
> 
> >    >:    -long file name support
> 
> > ...like unlimited (at least the filesystem switch shouldn't impose a
> > limit).
> 
> Yes, and in the AOL-esque sense, I can just image a file name that spans 
> five screens full of path and name, just to contain a "Me too" as the data.
> 
> How would one store, and iterate a filesystem where filenames could be 
> any size? Would one open a system file called "Directory", and use a 
> system-supplied database utility to iterate the files?
> 
> Far better would be a (say) 1024 limit on the total path size. So from 
> the root directory to the end of the filename would total not more than 
> 1024 chars.

How 'bout a max of about 256 characters. The first thirty or so would be
displayed in most cases ie. dialog boxes, icon layouts etc. but the next
220 could be displayed by option clicking (or whatever) I realy don't see
any use for more thatn 256.

On the topic of file systems I think the idea of newton-esque data "soup"
is cool (i have used a newton quite a bit.) however, how would that work
for transfering specific pecies of data across networks or on floppys?


Steven Blakey

In <dblakey-1808951440240001@dblakey.wat.hookup.net>, dblakey@hookup.net (Steven Blakey) writes:
>In article <412c9o$ll3@inca01.inca.co.nz>, gmiller@inca.co.nz (Gaven
>Miller) wrote:
>
>> Robert Krawitz (rlk@laraby.tiac.net) wrote:
>> 
>> >    >:    -long file name support
>> 
>> > ...like unlimited (at least the filesystem switch shouldn't impose a
>> > limit).
>> 
>> Yes, and in the AOL-esque sense, I can just image a file name that spans 
>> five screens full of path and name, just to contain a "Me too" as the data.
>> 
>> How would one store, and iterate a filesystem where filenames could be 
>> any size? Would one open a system file called "Directory", and use a 
>> system-supplied database utility to iterate the files?
>> 
>> Far better would be a (say) 1024 limit on the total path size. So from 
>> the root directory to the end of the filename would total not more than 
>> 1024 chars.
>
>How 'bout a max of about 256 characters. The first thirty or so would be
>displayed in most cases ie. dialog boxes, icon layouts etc. but the next
>220 could be displayed by option clicking (or whatever) I realy don't see
>any use for more thatn 256.
>
>On the topic of file systems I think the idea of newton-esque data "soup"
>is cool (i have used a newton quite a bit.) however, how would that work
>for transfering specific pecies of data across networks or on floppys?
>
>
>Steven Blakey

I, too, really like the way Newtons store data. It's really a lot simpler than 
constantly debating maximum file- and path- lengths (for the record, I think
that files should have a maximum of 50 characters [who really needs a 255-
character name?], and pathnames should be of unlimited length). As for data
transfer, it could be accomplished the same way Newtons do it now. Simple
yet advanced-- THAT will make a Dream OS.

BTW, what do we call the filesystem? DreamFS? ;)

Shawn Dessaigne
/-------------------------------------------------\
|pierrot@jersey.net      |"It's difficult to work |
|pgfs89c@prodigy.com     |a group when you're     |
|------------------------|omnipotent." -Q         |
|OS/2, Amiga, Apple IIgs,|------------------------|
|Epson QX-10, Epson QX-16|    WHS Class of '97    |
\-------------------------------------------------/

whats wrong with giving a user a choice, whether or not to make a path 
statment five pages long.  If someone had enough time to type all that 
text in, just for a file that said "me too", so be it.  does that effect 
you? of course not.  if it does, you can change it with mv easily.  whats 
wrong with a choice.  I usually dont give filenames that are over 10 
chars long, but if i need it it is there.  I am always sad when i work on 
a ms-dog machine because my "unique" file names always seem to repeat on 
the 8+3 schem, on unix/linux, it does not.

your idea of how to store long file names is almost correct.  in unix, 
directories are nothing more that specaily named files.  these files 
contain the long filename and its i-node information(another break thru 
for file storage) so one could say that, yes each directory has its own 
little database called directory infomation, and that is all it takes, 
you dont need an SQL server to keep track of you file system or anything 
like that.   it is simple and fast and efficent, what else do you expect 
from UNIX/Linux? 

-------------------------------------------------
Jeffery Walker                  Auburn University
04 CPE                       Computer Engineering
walkej2@eng.auburn.edu
"Real programmers don't document.  If it was hard
to write, it should be hard to understand."
-------------------------------------------------

On 18 Aug 1995, Gaven Miller wrote:

> Robert Krawitz (rlk@laraby.tiac.net) wrote:
> 
> >    >:    -long file name support
> 
> > ...like unlimited (at least the filesystem switch shouldn't impose a
> > limit).
> 
> Yes, and in the AOL-esque sense, I can just image a file name that spans 
> five screens full of path and name, just to contain a "Me too" as the data.
> 
> How would one store, and iterate a filesystem where filenames could be 
> any size? Would one open a system file called "Directory", and use a 
> system-supplied database utility to iterate the files?
> 
> Far better would be a (say) 1024 limit on the total path size. So from 
> the root directory to the end of the filename would total not more than 
> 1024 chars.
> 
> 
>