Naive HAMMER question

[Bill Hacker]

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 at 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....