Re: Filesystem syntax constraints under Windows

From	Don Y <this@is.not.me.com>
Newsgroups	comp.arch.embedded
Subject	Re: Filesystem syntax constraints under Windows
Date	2014-10-10 13:36 -0700
Organization	Aioe.org NNTP Server
Message-ID	<m19g8f$77j$1@speranza.aioe.org> (permalink)
References	(3 earlier) <m18qdl$ckj$1@speranza.aioe.org> <m18qj7$ckj$2@speranza.aioe.org> <m190q4$e3$1@dont-email.me> <m196n3$f0a$1@speranza.aioe.org> <m1988b$r4v$1@dont-email.me>

Show all headers | View raw

Hi Dimiter,

On 10/10/2014 11:24 AM, Dimiter_Popoff wrote:
>  >
>> That's exactly what I *don't* want to do!
>>
>> I want an object to be able to define the rules for what constitutes
>> a legitimate identifier IN IT'S SCOPE in whatever manner it wants.
>> For example, an IPv6 address should be allowed in the namespace
>> (of an object that expects to deal with IPv6 addresses!).  You shouldn't
>> have to map some character with arbitrarily imposed "special meaning"
>> (e.g., ':') to some OTHER character -- just because the filesystem's
>> naming rules didn't anticipate using it *in* an identifier.
>>
>> [Ditto '/' or '\']
>
> Well you will always need to define word (or argument) separators etc.
> So you will always have to map this to that at times, I don't think
> you can avoid that if you expect a human to be the end user of the
> system speaking English or sort of alphabet based language.
> File names are meant for human consumption so they do bear the legacy
> of human languages, there is no way around that.

But that's the difference:  other OS's have "file systems".  I don't.
I have "object namespaces".  There are no "files" in my system.
No "Windows Explorer" that a user plays with to locate "objects".

I could just as easily assign each object a 64b global identifier that
represents it's "address" in some "memory space".

Once you have opened a file, network connection, etc. does your code ever
think about it's *name*, again?  There's just an identifier somewhere in
your code that connects it to the object in question.  E.g., a network
connection is just a tuple -- never has a "name".

I only need a bridge to other OS's (Windows in this example) to get
things into or out of the system.  E.g., if a user wants to print a
diagnostic log from process 345345, he needs a "handle" to access
that (or, a mechanism that effectively/implicitly provides that handle).

The other identifiers are used by the objects *in* the system to
relate to *other* objects in the system.  I.e., there is no notion of
a user browsing my "namespace universe" from some "root node".  Because
most of it is meaningless to the user -- and often ephemeral.

"Gee, where did that mutex go?  It was here a moment ago!"

>> Likewise, I often encounter cases where I am importing a set of files
>> created under UN*X and find name collisions where names differ only
>> by issues of case.  It seems counterintuitive to come up with a new
>> scheme that has *less* capability than an existing one.  :-/
>
> Well detection of duplicate names is _more_ capabilities in my book :-).
> Just as failure to find a name because someone typed it in a
> different case is _less_ capabilities.
> The proper handling of a duplicate name coming from a unix directory
> would be to read the name, detect the duplication and rename using some
> convention, possibly just append something past the duplicate part
> (so it can easily be found by partial compare).

Then things break.  Because you can't know where all references
to that "duplicate" name exist.  It *wasn't* a duplicate in the
original (UNIX) context.  E.g., a makefile that refers to foo.S
and NOT foo.s may now end up referencing foo.s, instead (if foo.S
was detected as the "duplicate")

>>> The worst issue
>>> I have is with names containing spaces; treating those in a script
>>> makes word count variable, preserving space count between words must
>>> be addressed, forwarding a name which was in quotation marks which
>>> get "eaten" during the former processing etc. etc. If you can
>>> afford to disallow spaces in names things will be much simpler.
>>> Which is not really practical as other systems do allow spaces,
>>> so we have to handle this as well.
>>
>> Exactly.  Building on what you say below, should we just ignore
>> embedded whitespace (just like ignoring alphabetic case?).
>> So, "Avery Littleman" and "A Very Little Man" and "AVERYLITTLEMAN"
>> are all the same?  :-/
>
> No, space is a symbol. It just has no upper case, similar to
> digits, punctuation etc.

My point was spaces cause issues -- case sensitivity is an "issue"
in your book.  Why not "fix" the space issue in a manner similar to
the case one?  Just ignore them!  Allow "A      Very Little   Man"
to be treated as "AVERYLITTLEMAN" -- that way the user doesn't have
to worry about remembering how *many* spaces or *if* there were
spaces!

The "cost" (to the user) is just a shrinking of the namespace.
In much the same way that case insensitivity shrinks the namespace.

>>> As a side note, "the right way" to treat file names is to preserve
>>> the case information and to ignore it during file search (i.e.
>>> aaa and AAA locate the same file). Obviously unix machines will
>>> have the improper case treatment problem forever but it is
>>> their problem after all, they have saved a few minutes of
>>> thinking back when they created it. My solution to that was to
>>> do the right thing and allow also the wrong thing to be done;
>>> i.e. if you compare the textual part of the name (which is stored
>>> as upper (or was it lower) case only) you locate the same file,
>>> if you want to distinguish also by case you have to compare
>>> another few bytes which carry the case bits for the textual
>>> part. But I am not sure I even made a call doing the case dependent
>>> search, if I do I have never used it so far anyway.
>>
>> I disagree.  And, I think your comments reflect a particular manner in
>> which you see filenames used.  I.e., exposed to the user to name
>> objects (files) that he has created.
>
> Yes, if you build on the assumption that a "name" is something not
> meant for human consumption the better way would be to use bytes,
> not text.

Why force the representation to be "difficult to read" (by the
developer)?  There's a large, available domain of names, why keep
the developer from picking names that are "significant" to him?

Why not label all variables in a form:  V####?

> But humans are constantly using files which are named, so a "file name"
> is basically meant for human consumption, this is much of what
> filesystems are about really.

Again, I'm not dealing with a filesystem but, rather, a namespace.
Does the user care if the task that runs the air conditioner is
called "AirConditioner" vs. "10034566"?  If the user never has to
interact with it, then the choice of identifier is not one of his
concerns.

OTOH, why should the developer have to pick a unique N-bit number
to refer to "the task that runs the air conditioner"?  And, another
one to refer to the diagnostic log generated by that task?  etc.

How many "objects" exist inside your cell phone for which NO "user
visible name" exists?  Or, your "smart TV"/media tank?

The things that the user must be able to access/reference are the
only ones that need to have names (and access mechanisms) that are
"user friendly".

But, EVERY object has a name -- including those that are intended
to be (or potentially) visible to the user.  The problem that I am
trying to address is how to make those names visible in a particular
environment (e.g., Windows) *without* impacting the choice that the
developer has to make in creating their "native names".

It looks like the only way to accomplish this -- given Windows'
limitations/constraints -- is to create another "exported" namespace
that maps the developer's names to names that Windows will tolerate.

That's not a big deal -- namespaces are an abundant commodity (and,
things that the user is likely to need to see will be largely
static in their names).  But, it means planning on these other
"exportable" namespaces when crafting those parts of the code.
I.e., I can't just tag existing names and toss them, as is, into
a container created for export.

This should let me get around any other "restrictions" of a foreign
OS.  E.g., I could handle 8.3 names just as easily -- though that
may annoy a user having to sort out what they *mean* in such a
highly abbreviated form!  (But, that's consistent with the
tail/dog comment I made before -- he's stuck in 8.3 land so that's
*his* problem... not something that I need to impose on folks
working in richer environments!)

Thread

Filesystem syntax constraints under Windows Don Y <this@is.not.me.com> - 2014-10-10 00:31 -0700
  Re: Filesystem syntax constraints under Windows glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-10-10 09:06 +0000
    Re: Filesystem syntax constraints under Windows David Brown <david.brown@hesbynett.no> - 2014-10-10 13:32 +0200
      Re: Filesystem syntax constraints under Windows Don Y <this@is.not.me.com> - 2014-10-10 07:23 -0700
        Re: Filesystem syntax constraints under Windows Don Y <this@is.not.me.com> - 2014-10-10 07:26 -0700
          Re: Filesystem syntax constraints under Windows Dimiter_Popoff <dp@tgi-sci.com> - 2014-10-10 19:17 +0300
            Re: Filesystem syntax constraints under Windows David Brown <david.brown@hesbynett.no> - 2014-10-10 19:12 +0200
              Re: Filesystem syntax constraints under Windows Dimiter_Popoff <dp@tgi-sci.com> - 2014-10-10 20:34 +0300
              Re: Filesystem syntax constraints under Windows Don Y <this@is.not.me.com> - 2014-10-10 11:32 -0700
            Re: Filesystem syntax constraints under Windows Don Y <this@is.not.me.com> - 2014-10-10 10:53 -0700
              Re: Filesystem syntax constraints under Windows Dimiter_Popoff <dp@tgi-sci.com> - 2014-10-10 21:24 +0300
                Re: Filesystem syntax constraints under Windows Don Y <this@is.not.me.com> - 2014-10-10 13:36 -0700
                Re: Filesystem syntax constraints under Windows Dimiter_Popoff <dp@tgi-sci.com> - 2014-10-11 00:18 +0300
                Re: Filesystem syntax constraints under Windows Don Y <this@is.not.me.com> - 2014-10-10 15:28 -0700
                Re: Filesystem syntax constraints under Windows Tonton Th <tTh@nowhere.invalid> - 2014-10-12 20:07 +0000
                Re: Filesystem syntax constraints under Windows Don Y <this@is.not.me.com> - 2014-10-12 19:52 -0700
              Re: Filesystem syntax constraints under Windows Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2014-10-10 21:15 +0200
                Re: Filesystem syntax constraints under Windows Dimiter_Popoff <dp@tgi-sci.com> - 2014-10-10 23:04 +0300
            Re: Filesystem syntax constraints under Windows Stefan Reuther <stefan.news@arcor.de> - 2014-10-11 11:28 +0200
              Re: Filesystem syntax constraints under Windows Dimiter_Popoff <dp@tgi-sci.com> - 2014-10-11 17:13 +0300
                Re: Filesystem syntax constraints under Windows David Brown <david.brown@hesbynett.no> - 2014-10-11 17:26 +0200
                Re: Filesystem syntax constraints under Windows Dimiter_Popoff <dp@tgi-sci.com> - 2014-10-11 18:51 +0300
                Re: Filesystem syntax constraints under Windows Stefan Reuther <stefan.news@arcor.de> - 2014-10-12 12:04 +0200
                Re: Filesystem syntax constraints under Windows Dimiter_Popoff <dp@tgi-sci.com> - 2014-10-12 15:59 +0300
                Re: Filesystem syntax constraints under Windows Don Y <this@is.not.me.com> - 2014-10-12 08:04 -0700
                Re: Filesystem syntax constraints under Windows Dimiter_Popoff <dp@tgi-sci.com> - 2014-10-12 18:47 +0300
                Re: Filesystem syntax constraints under Windows Don Y <this@is.not.me.com> - 2014-10-12 09:01 -0700
                Re: Filesystem syntax constraints under Windows Don Y <this@is.not.me.com> - 2014-10-12 09:05 -0700
                Re: Filesystem syntax constraints under Windows Dimiter_Popoff <dp@tgi-sci.com> - 2014-10-12 19:17 +0300
                Re: Filesystem syntax constraints under Windows Stefan Reuther <stefan.news@arcor.de> - 2014-10-13 19:26 +0200
                Re: Filesystem syntax constraints under Windows Dimiter_Popoff <dp@tgi-sci.com> - 2014-10-13 22:00 +0300
                Re: Filesystem syntax constraints under Windows David Brown <david.brown@hesbynett.no> - 2014-10-14 10:25 +0200
                Re: Filesystem syntax constraints under Windows Dimiter_Popoff <dp@tgi-sci.com> - 2014-10-14 13:28 +0300
                Re: Filesystem syntax constraints under Windows David Brown <david.brown@hesbynett.no> - 2014-10-14 14:37 +0200
                Re: Filesystem syntax constraints under Windows Dimiter_Popoff <dp@tgi-sci.com> - 2014-10-14 16:00 +0300
                Re: Filesystem syntax constraints under Windows Don Y <this@is.not.me.com> - 2014-10-14 06:19 -0700
                Re: Filesystem syntax constraints under Windows Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2014-10-15 19:57 +0200
                Re: Filesystem syntax constraints under Windows Dimiter_Popoff <dp@tgi-sci.com> - 2014-10-16 00:06 +0300
                Re: Filesystem syntax constraints under Windows Stefan Reuther <stefan.news@arcor.de> - 2014-10-16 18:16 +0200
                Re: Filesystem syntax constraints under Windows Dimiter_Popoff <dp@tgi-sci.com> - 2014-10-16 20:49 +0300
                Re: Filesystem syntax constraints under Windows Stefan Reuther <stefan.news@arcor.de> - 2014-10-14 18:59 +0200
                Re: Filesystem syntax constraints under Windows Dimiter_Popoff <dp@tgi-sci.com> - 2014-10-14 21:39 +0300
                Re: Filesystem syntax constraints under Windows David Brown <david.brown@hesbynett.no> - 2014-10-14 23:29 +0200
                Re: Filesystem syntax constraints under Windows Dimiter_Popoff <dp@tgi-sci.com> - 2014-10-15 00:46 +0300
                Re: Filesystem syntax constraints under Windows David Brown <david.brown@hesbynett.no> - 2014-10-15 01:38 +0200
        Re: Filesystem syntax constraints under Windows David Brown <david.brown@hesbynett.no> - 2014-10-10 17:31 +0200
          Re: Filesystem syntax constraints under Windows Don Y <this@is.not.me.com> - 2014-10-10 10:34 -0700
    Re: Filesystem syntax constraints under Windows Don Y <this@is.not.me.com> - 2014-10-10 06:59 -0700
  Re: Filesystem syntax constraints under Windows Stefan Reuther <stefan.news@arcor.de> - 2014-10-10 18:42 +0200
    Re: Filesystem syntax constraints under Windows glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-10-10 19:00 +0000
    Re: Filesystem syntax constraints under Windows Don Y <this@is.not.me.com> - 2014-10-10 13:43 -0700
      Re: Filesystem syntax constraints under Windows upsidedown@downunder.com - 2014-10-11 11:06 +0300
        Re: Filesystem syntax constraints under Windows Don Y <this@is.not.me.com> - 2014-10-11 01:35 -0700
        Re: Filesystem syntax constraints under Windows Dimiter_Popoff <dp@tgi-sci.com> - 2014-10-11 17:24 +0300
        Re: Filesystem syntax constraints under Windows David Brown <david.brown@hesbynett.no> - 2014-10-11 17:43 +0200
          Re: Filesystem syntax constraints under Windows Stefan Reuther <stefan.news@arcor.de> - 2014-10-12 12:07 +0200
            Re: Filesystem syntax constraints under Windows David Brown <david.brown@hesbynett.no> - 2014-10-12 23:41 +0200
              Re: Filesystem syntax constraints under Windows Stefan Reuther <stefan.news@arcor.de> - 2014-10-13 19:14 +0200
                Re: Filesystem syntax constraints under Windows David Brown <david.brown@hesbynett.no> - 2014-10-13 20:18 +0200
                Re: Filesystem syntax constraints under Windows Mel Wilson <mwilson@the-wire.com> - 2014-10-15 18:43 +0000
                Re: Filesystem syntax constraints under Windows David Brown <david.brown@hesbynett.no> - 2014-10-15 21:58 +0200
                Re: Filesystem syntax constraints under Windows George Neuner <gneuner2@comcast.net> - 2014-10-15 23:55 -0400
    Re: Filesystem syntax constraints under Windows Don Y <this@is.not.me.com> - 2014-10-20 09:45 -0700
      Re: Filesystem syntax constraints under Windows Stefan Reuther <stefan.news@arcor.de> - 2014-10-21 18:47 +0200
        Re: Filesystem syntax constraints under Windows Don Y <this@is.not.me.com> - 2014-10-21 15:38 -0700
          Re: Filesystem syntax constraints under Windows Don Y <this@is.not.me.com> - 2014-10-21 17:51 -0700
          Re: Filesystem syntax constraints under Windows George Neuner <gneuner2@comcast.net> - 2014-10-22 01:35 -0400
            Re: Filesystem syntax constraints under Windows Don Y <this@is.not.me.com> - 2014-10-21 23:22 -0700
              Re: Filesystem syntax constraints under Windows Stefan Reuther <stefan.news@arcor.de> - 2014-10-22 18:39 +0200
                Re: Filesystem syntax constraints under Windows Don Y <this@is.not.me.com> - 2014-10-22 11:34 -0700
                Re: Filesystem syntax constraints under Windows upsidedown@downunder.com - 2014-10-22 22:11 +0300
            Re: Filesystem syntax constraints under Windows glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-10-23 00:20 +0000
              Re: Filesystem syntax constraints under Windows George Neuner <gneuner2@comcast.net> - 2014-10-23 01:36 -0400
                Re: Filesystem syntax constraints under Windows glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-10-23 09:08 +0000
                Re: Filesystem syntax constraints under Windows George Neuner <gneuner2@comcast.net> - 2014-10-23 14:50 -0400
                Re: Filesystem syntax constraints under Windows Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2014-10-23 21:42 +0200
      Re: Filesystem syntax constraints under Windows Dimiter_Popoff <dp@tgi-sci.com> - 2014-10-22 01:21 +0300
        Re: Filesystem syntax constraints under Windows Don Y <this@is.not.me.com> - 2014-10-21 15:51 -0700
          Re: Filesystem syntax constraints under Windows glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-10-21 23:27 +0000
            Re: Filesystem syntax constraints under Windows Don Y <this@is.not.me.com> - 2014-10-21 16:50 -0700
            Re: Filesystem syntax constraints under Windows Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2014-10-22 21:00 +0200
              Re: Filesystem syntax constraints under Windows upsidedown@downunder.com - 2014-10-22 22:54 +0300
          Re: Filesystem syntax constraints under Windows Dimiter_Popoff <dp@tgi-sci.com> - 2014-10-22 02:32 +0300
            Re: Filesystem syntax constraints under Windows Don Y <this@is.not.me.com> - 2014-10-21 17:21 -0700
              Re: Filesystem syntax constraints under Windows Dimiter_Popoff <dp@tgi-sci.com> - 2014-10-22 03:52 +0300
                Re: Filesystem syntax constraints under Windows Don Y <this@is.not.me.com> - 2014-10-21 21:13 -0700
            Re: Filesystem syntax constraints under Windows David Brown <david.brown@hesbynett.no> - 2014-10-22 08:10 +0200
              Re: Filesystem syntax constraints under Windows Dimiter_Popoff <dp@tgi-sci.com> - 2014-10-22 12:00 +0300
                Re: Filesystem syntax constraints under Windows David Brown <david.brown@hesbynett.no> - 2014-10-22 13:11 +0200
                Re: Filesystem syntax constraints under Windows Dimiter_Popoff <dp@tgi-sci.com> - 2014-10-22 15:19 +0300
                Re: Filesystem syntax constraints under Windows David Brown <david.brown@hesbynett.no> - 2014-10-22 15:21 +0200
                Re: Filesystem syntax constraints under Windows Dimiter_Popoff <dp@tgi-sci.com> - 2014-10-22 17:26 +0300
                Re: Filesystem syntax constraints under Windows Stefan Reuther <stefan.news@arcor.de> - 2014-10-22 18:46 +0200
                Re: Filesystem syntax constraints under Windows Dimiter_Popoff <dp@tgi-sci.com> - 2014-10-23 02:37 +0300
                Re: Filesystem syntax constraints under Windows David Brown <david.brown@hesbynett.no> - 2014-10-22 23:09 +0200
                Re: Filesystem syntax constraints under Windows Dimiter_Popoff <dp@tgi-sci.com> - 2014-10-23 03:06 +0300
                Re: Filesystem syntax constraints under Windows David Brown <david.brown@hesbynett.no> - 2014-10-23 10:18 +0200
                Re: Filesystem syntax constraints under Windows Dimiter_Popoff <dp@tgi-sci.com> - 2014-10-23 13:56 +0300
                Re: Filesystem syntax constraints under Windows David Brown <david.brown@hesbynett.no> - 2014-10-23 15:59 +0200

csiph-web