Re: Naive HAMMER question

[Bill Hacker <wbh@xxxxxxxxxxxxx>]

Matthew Dillon wrote:
> :The character encoding has to be specified somewhere.  Do we envision
> :having differently encoded filenames on the same filesystem?  Filenames
> :that are encoded differently than the contents of the file itself?  Does
> :the filesystem need to know if a file's contents even have an encoding?
> :
> :I'm sure these are very old questions, but I know little about how file-
> :systems are designed because I've never designed one (and I'm glad :o)
>
>     My personal opinion is with Bill on this one... the filesystems, and
>     possibly even the kernel, should just be neutral about the whole mess
>     and allow (or at least not disallow) binary encodings, which is pretty
>     much how it works now.

[WBH]
Carrying encoding deeper than it otherwise needs to be also adds a great 
deal of work to insure consistency. That need is pervasive and never-ending.

Such overhead is avoidable if the lower levels remain as pure-binary and 
usage-agnostic as possible.

'Lazy is good' on this score, because it puts up fewer barriers to 
change, and imposes lighter restrictions on apps and userlandd.


>     At most I see having a kernel layer to help userland support encodings
>     but I don't see the filesystem having one, and I don't see either the
>     kernel or the filesystem doing anything sophisticated.
>
> 					-Matt
> 					Matthew Dillon 
> 					<dillon@backplane.com>

As to the fs side - have a look here (imperfect - but handy):

http://en.wikipedia.org/wiki/Comparison_of_file_systems

Note - page down - that most 'modern' fs allow a directory name to include:

'any valid byte but null'

A few allow 'any valid unicode but null' [1]

Fewer still allow 'any valid unicode' (implying null included?). [2]

What does HAMMER actually need to keep it flexible, 'grow-able'  and 
compatible with file transfers?

Bill


[1] UTF8 originated with Plan 9, became far more widely used than the OS 
itself - but seems to have had no visible affect on the fortunes of 
Plan9 per se.

[2] Not clearly shown on that page, but ISTR that is Apple's current 
'hfs' and 'hfs+', NOT Apple's original 'hfs', nor is it HP's 
similarly-named-but-different 'HFS'.

Ironically, I can't test it on MY Mac's as '*BSD'ie that I am, my first 
act in OS X setup is to reformat the drives to all-UFS....