Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #18498 > unrolled thread

Filesystem syntax constraints under Windows

Back to article view | Back to comp.arch.embedded

Contents

  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

Page 1 of 5  [1] 2 3 4 5  Next page →

#18498 — Filesystem syntax constraints under Windows

Hi,

Does anyone know which filesystem naming constraints are imposed
in Windows itself vs. the file system layer?  Said another way,
which constraints are *invariants* regardless of the filesystem?

E.g., can a non-native filesystem redefine '+' to replace "../"?
Or, allow support for ':' in names?  Or, replace '\' with '/'?
Or, ...

Thx,
--don

[toc] | [next] | [standalone]

#18500

Don Y <this@is.not.me.com> wrote:
 
> Does anyone know which filesystem naming constraints are imposed
> in Windows itself vs. the file system layer?  Said another way,
> which constraints are *invariants* regardless of the filesystem?
 
> E.g., can a non-native filesystem redefine '+' to replace "../"?
> Or, allow support for ':' in names?  Or, replace '\' with '/'?
> Or, ...

Interesting question.

It is well known that the actual system calls accept either / or \
as a separator.  The command option processor uses / for options,
and so requires \ for the separator.

The more interesting cases come when you use NFS. 

I was just reading yesterday that it is possible to have an NFS
server on a Windows system that allows for case significant names.
(Unlike most that are case preserving.) 

The NFS protocols are independent of the actual separator. 

The : in drive selection has to be processed pretty early.
I am not so sure what to say about : later in the name. 

As far as I know, CMD has to keep track of the current 
subdirectory. That would complicate any other treatment
for \ and :.

-- glen

[toc] | [prev] | [next] | [standalone]

#18503

On 10/10/14 11:06, glen herrmannsfeldt wrote:
> Don Y <this@is.not.me.com> wrote:
>  
>> Does anyone know which filesystem naming constraints are imposed
>> in Windows itself vs. the file system layer?  Said another way,
>> which constraints are *invariants* regardless of the filesystem?
>  
>> E.g., can a non-native filesystem redefine '+' to replace "../"?
>> Or, allow support for ':' in names?  Or, replace '\' with '/'?
>> Or, ...
> 
> Interesting question.
> 
> It is well known that the actual system calls accept either / or \
> as a separator.  The command option processor uses / for options,
> and so requires \ for the separator.
> 
> The more interesting cases come when you use NFS. 
> 
> I was just reading yesterday that it is possible to have an NFS
> server on a Windows system that allows for case significant names.
> (Unlike most that are case preserving.) 

I believe you can store case-sensitive named files on NTFS as well -
it's part of the posix compliance of the filesystem (harking back to the
days when MS were still pretending to cooperate with other OS's).

Don, why are you asking about this?  Are you trying to implement a
non-native filesystem and want to support as much as Windows allows?  If
so, then the answer might depend on how that filesystem interacts with
Windows.  (I am not sure that I can give you more information no matter
what you answer - but it might be of some help.)

Even if it is possible to redefine things like directory separators, it
might cause a lot more confusion and therefore not be worth implementing
(just like using files whose names differ only by letter case).

Also consider path lengths in this - the path length limitations are
different within Windows itself and in NTFS.

[toc] | [prev] | [next] | [standalone]

#18505

Hi David,

On 10/10/2014 4:32 AM, David Brown wrote:
> On 10/10/14 11:06, glen herrmannsfeldt wrote:
>> Don Y <this@is.not.me.com> wrote:
>>
>>> Does anyone know which filesystem naming constraints are imposed
>>> in Windows itself vs. the file system layer?  Said another way,
>>> which constraints are *invariants* regardless of the filesystem?
>>
>>> E.g., can a non-native filesystem redefine '+' to replace "../"?
>>> Or, allow support for ':' in names?  Or, replace '\' with '/'?
>>> Or, ...
>>
>> Interesting question.
>>
>> It is well known that the actual system calls accept either / or \
>> as a separator.  The command option processor uses / for options,
>> and so requires \ for the separator.
>>
>> The more interesting cases come when you use NFS.
>>
>> I was just reading yesterday that it is possible to have an NFS
>> server on a Windows system that allows for case significant names.
>> (Unlike most that are case preserving.)
>
> I believe you can store case-sensitive named files on NTFS as well -
> it's part of the posix compliance of the filesystem (harking back to the
> days when MS were still pretending to cooperate with other OS's).

Preserving (and even *enforcing*) case doesn't guarantee that
identifiers differing *solely* in case can coexist in the same
container!  E.g., ReadMe, READme, ReAdMe, etc.

> Don, why are you asking about this?  Are you trying to implement a
> non-native filesystem and want to support as much as Windows allows?  If
> so, then the answer might depend on how that filesystem interacts with
> Windows.  (I am not sure that I can give you more information no matter
> what you answer - but it might be of some help.)

I don't have a filesystem.  Rather, the typical filesystem concept
is used to manage a universe of (possibly parallel) nested namespaces.
Each object defines the rules for the namespace(s) that it exports.
I.e., the valid syntax for identifying portions *of* that object.

So, a "directory/folder" (to use a familiar concept) might support
objects named:
- ReadMe.txt
- README.TXT
- Read/\/\e
- Garage:Door:Actuator
- OutsideTemperature

The Garage:Door:Opener object might support objects (methods) named "open"
and "close" and "current_state".

I want to be able to make any of these named objects accessible under
various other environments.  If the host OS('s) enforce their own
concept of "what constitutes a name", then I either have to adopt names
FOR EXPORTED OBJECTS that are compatible with those OS('s) -- i.e.,
some GCD thereof -- or provide a translation interface (create a
parallel namespace for exported objects such that the exported names
comply with the rules of the host OS).

OTOH, if name parsing is left to the filesystem implementation (i.e.,
as it is in my implementation), then all I have to do is port my
implementation to each of those host OS's.

> Even if it is possible to redefine things like directory separators, it
> might cause a lot more confusion and therefore not be worth implementing
> (just like using files whose names differ only by letter case).

I'm not keen on letting the tail wag the dog.  If Windows has a limitation,
that's Windows' problem.  I'd be comfortable having Windows users bear the
inconvenience of Windows' limitations (just like I wouldn't restrict myself
to 8.3 names just to make life easy for DOS users).

> Also consider path lengths in this - the path length limitations are
> different within Windows itself and in NTFS.

Yes.  But I think much of that issue inherently "goes away" when addressed
as an exported namespace.  I.e., ONLY what the (Windows) user needs to see
has to be made available to him/her.  And, at some convenient "mount point"
(I guess that's still "drive letter" in the MS world).

So, the exported namespace can represent:
     some/very/long/traditional/pathname/to/a/file as "file"
     some/other/file as "file2"
     some.particular\method as "verb"
     That(&*^@$%(Fool as "A_Fine_Gentleman"

[note I've tried to show how to accommodate the host's naming rules as well]

[toc] | [prev] | [next] | [standalone]

#18506

On 10/10/2014 7:23 AM, Don Y wrote:
> So, the exported namespace can represent:
>      some/very/long/traditional/pathname/to/a/file as "file"
>      some/other/file as "file2"
>      some.particular\method as "verb"
>      That(&*^@$%(Fool as "A_Fine_Gentleman"

In case it wasn't obvious:  to the "external system", this LOOKS
like a single "directory" with four names in it.  It is *flat*!
(despite the fact that the objects all existed at different
"places"/levels in the system exporting them)

[toc] | [prev] | [next] | [standalone]

#18509

On 10.10.2014 г. 17:26, Don Y wrote:
> On 10/10/2014 7:23 AM, Don Y wrote:
>> So, the exported namespace can represent:
>>      some/very/long/traditional/pathname/to/a/file as "file"
>>      some/other/file as "file2"
>>      some.particular\method as "verb"
>>      That(&*^@$%(Fool as "A_Fine_Gentleman"
>
> In case it wasn't obvious:  to the "external system", this LOOKS
> like a single "directory" with four names in it.  It is *flat*!
> (despite the fact that the objects all existed at different
> "places"/levels in the system exporting them)
>

Hi Don,

as David already suggested your best chance is to limit what you
accept (and thus have to process) as much as practical.
The problems are by far not just related to how this or that
character is treated; e.g. at the moment I am struggling with
how I process names in _my_ dps scripts using _my_ longnamed directories
to be compatible with _my_ older 8.4 directories. 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.

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.

Dimiter

------------------------------------------------------
Dimiter Popoff, TGI             http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/

[toc] | [prev] | [next] | [standalone]

#18512

On 10/10/14 18:17, Dimiter_Popoff wrote:

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

This is getting a bit off topic from Don's question, but it is very
clearly a matter of opinion as to what is "the right way" to handle file
name cases.

I would say that the unix way is the only sensible way, because it is
transparent and consistent - the system does not care about the
characters used, and does not make any artificial and language-specific
distinctions.  When people started using UTF-8 filenames, the unix way
needed no changes, and everything continues as normal.

But if you start trying to say that some characters are equivalent to
particular other characters, you have an endless task as soon as you
start looking at anything other than plain English.  How is the OS, or
programs running on it, going to figure out that é and É are the same
letter but different capitalisation?  And why artificially decide that
small and large letters in the English alphabet are equivalent - what
about other combinations that are considered the same letter(s) in other
languages?  In German, you sometimes use "ss" and sometimes "ß" - they
should be treated the same.  In Norwegian, in some cases you would
consider "aa" the same as "å" (this causes great fun when sorting names
- "å" comes at the end of the alphabet, but names beginning with "Aa"
should be sorted alongside those beginning with "Å").  In Arabic, there
are (AFAIUI) 5 different characters for each letter - should these be
considered equivalent in file names?

I have no doubt that in a well-designed OS and filesystem, you either
have to treat different cases as completely distinct, or you limit the
whole system to 7-bit ASCII.

[toc] | [prev] | [next] | [standalone]

#18513

On 10.10.2014 г. 20:12, David Brown wrote:
> ...
>
> This is getting a bit off topic from Don's question, but it is very
> clearly a matter of opinion as to what is "the right way" to handle file
> name cases.
>
> I would say that the unix way is the only sensible way, because it is
> transparent and consistent - the system does not care about the
> characters used, and does not make any artificial and language-specific
> distinctions.  When people started using UTF-8 filenames, the unix way
> needed no changes, and everything continues as normal.

Not at all. A "name" is composed of text; text is written using
some alphabet and the alphabets I know of (Latin and its variations,
Cyrillic with its ones) are used by languages in upper and lower
case universally. I don't know how this is with hieroglyph based
languages so I leave these out of my comment - these would be
subject to completely different treatment anyway.
A name - e.g. DAVID or David, refers to the same name bearer in
any language I can think of. File names are names and are intended
also for human consumption.

How we deal with that at the bit level is a separate matter;
the unix way in making DAVID differ from David is clearly wrong
and shortsighted.

> In German, you sometimes use "ss" and sometimes "ß" - they
> should be treated the same.

No, this is an exercise for some language processor. You store a
name the way it is spelt, case info and language-specific characters
choice upon entering it included.

The basic rule is that we do what has to be done and we don't do
what has to be done elsewhere; when storing a name we store a
name which is a text string (not just a sequence of bytes) and
nothing more than that (i.e. we do not apply any grammar rules
to it, we leave that for the name reader/writer).

Dimiter


------------------------------------------------------
Dimiter Popoff, TGI             http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/

[toc] | [prev] | [next] | [standalone]

#18518

On 10/10/2014 10:12 AM, David Brown wrote:

> I would say that the unix way is the only sensible way, because it is
> transparent and consistent - the system does not care about the
> characters used, and does not make any artificial and language-specific
> distinctions.  When people started using UTF-8 filenames, the unix way
> needed no changes, and everything continues as normal.

+1

> But if you start trying to say that some characters are equivalent to
> particular other characters, you have an endless task as soon as you
> start looking at anything other than plain English.  How is the OS, or
> programs running on it, going to figure out that é and É are the same
> letter but different capitalisation?  And why artificially decide that
> small and large letters in the English alphabet are equivalent - what
> about other combinations that are considered the same letter(s) in other
> languages?  In German, you sometimes use "ss" and sometimes "ß" - they
> should be treated the same.  In Norwegian, in some cases you would
> consider "aa" the same as "å" (this causes great fun when sorting names
> - "å" comes at the end of the alphabet, but names beginning with "Aa"
> should be sorted alongside those beginning with "Å").  In Arabic, there
> are (AFAIUI) 5 different characters for each letter - should these be
> considered equivalent in file names?

*Which* character set?  ARE NAMES EVEN PART OF *ANY* "CHARACTER SET"?
I.e., why can't a name be a series of "8 bit slices" out of some N bit
quantity?
   0x00 0x00 0x00 0x00
   0x00 0x00 0x00 0x01
   ...
(imagine how you would structure a "container" whose contents always
followed this sort of rule!  1,000,000+ "names" and any *one* could be
accessed in constant time!!)

They're *identifiers*.  All they have to be is uniquely resolvable.
They only have to make sense to the entities that reference them!

The cognitive stumbling block is getting away from them as identifiers
that the user (has to) deal with.  If you want to expose meaningful names
to a user, then map the "cumbersome" names to something more friendly
(in a parallel namespace).

E.g., think of the alphabet soup that Solaris uses to reference devices:
    ../../devices/pci@0,0/pci-ide@1f,2/ide@1/sd@0,0:q
and the "aliases" (i.e., names in a different namespace) that it
then applies to make life easy for mere mortals:
    /dev/dsk/c1t0d0p0
and a user-created symlink that makes life even easier:
    /bootpartition

> I have no doubt that in a well-designed OS and filesystem, you either
> have to treat different cases as completely distinct, or you limit the
> whole system to 7-bit ASCII.

[toc] | [prev] | [next] | [standalone]

#18516

Hi Dimiter,

[Sort out your display/tablet issue, yet?]

On 10/10/2014 9:17 AM, Dimiter_Popoff wrote:
>>> So, the exported namespace can represent:
>>>      some/very/long/traditional/pathname/to/a/file as "file"
>>>      some/other/file as "file2"
>>>      some.particular\method as "verb"
>>>      That(&*^@$%(Fool as "A_Fine_Gentleman"
>>
>> In case it wasn't obvious:  to the "external system", this LOOKS
>> like a single "directory" with four names in it.  It is *flat*!
>> (despite the fact that the objects all existed at different
>> "places"/levels in the system exporting them)

> as David already suggested your best chance is to limit what you
> accept (and thus have to process) as much as practical.

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 '\']

> The problems are by far not just related to how this or that
> character is treated; e.g. at the moment I am struggling with
> how I process names in _my_ dps scripts using _my_ longnamed directories
> to be compatible with _my_ older 8.4 directories.

If, OTOH, you had a more permissive implementation *before*, then
this problem wouldn't exist!

E.g., filenames of the form ".cshrc" annoy Windows (though you can
*trick* it to accept them... you just can't always *create* files
having such names).

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.  :-/

> 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?  :-/

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

I use names to identify objects that a piece of software (process)
can access.  Each process is created with its own, "personal"
namespace which has been populated by its parent/creator (and, in
doing so, *bound* to specific existing system objects known to its
parent).

So, a TOP LEVEL namespace might be:
    My PID
    stdin
    stdout
    stderr
    My kmem
    My Files/
    garage door

The process that that namespace serves is responsible for knowing which
names are important to it.  It's not like exposing an entire filesystem
to a user so he can indicate which *file* (collection of bytes on a medium)
he wants to access.

Instead, they are conventions (for the most part) that the parent knows
the child will observe.  So, the parent can bind "stderr" to the "stdin"
of some other process (with a completely disjoint namespace) and know
that the childs error messages will be processed by that "other" process.

Note that, in my scheme, you are free to implement a "user visible container
for files" (i.e., "a folder") and impose an entirely different set of
rules, therein.  When someone/thing tries to "walk" (parse_pathname)
through that folder, the method associated with that type of object
("user visible container for files") can opt to ignore case.  Or, treat
numbers as Roman numeral equivalents.  Or...

OTOH, if you impose some restriction on the *basic* name scheme, you
can never "enhance" it (without a lot of compatibility grief).

[toc] | [prev] | [next] | [standalone]

#18517

Hi Don,

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

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

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

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

Dimiter

------------------------------------------------------
Dimiter Popoff, TGI             http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/

[toc] | [prev] | [next] | [standalone]

#18524

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!)

[toc] | [prev] | [next] | [standalone]

#18526

Hi Don,

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

OK, I get that - in DPS this is the concept of runtime "objects",
which have a 16 byte "name" but it is not for user consumption.
I use text in it but this is just a matter of convenience when
I code. When the system searches for an object it just compares
bytes (well longwords in reality, it does that with filenames
too actually :-) ).

But we were talking of a "file system", and in a file system
one does have files which do have names some of which are created
by humans and supposed to be read/memorized by humans. At some
level we do need the text for the name stored and searchable.
If we just store the name text as bytes we end up needing
twice the search overhead to do it case independent; which is
why I think the unix makers back then left it case dependent,
did not want to be bothered. It takes only a little - a bit
per character - to do it the way it is done in DPS, and you
have the best of both worlds. Case-free name information followed
by the respective case bitstream. Somewhat more demanding to code but
completely doable, was that for me anyway.

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

Well if you do not need to reproduce the names you get back you
can simply hash the incoming names into what, 64 or may be just
32 bits and you are done. If you want to reproduce them forget
it, just storing them as you got them is the only sensible way
to go.
Which does not preclude you from "hashing" (in fact you can
just use the addresses of the stored names or sort of) for your
internal purposes, of course.

>
> 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?

Oh come on Don, we all know the alphabet here, let's not go over
it again.

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

Yes, for the dps objects I wrote earlier about I do that sort of
thing by making them do "listname" (or whatever the action was called).
The plainest of objects just paste as text ("paste" at an address
in memory, that is... :-) ) their 16 byte ID, more sophisticated
ones which must be shown to the user have something better to paste
(which may be static or not).
But generally there is not much else you can do, if you need two
different names for a thing you need two separate names, what can you
do.
OTOH common file systems pose very little restrictions which will
be in your way when you invent names during programming so I am
not sure at all you have a real issue here.

Dimiter

------------------------------------------------------
Dimiter Popoff, TGI             http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/

[toc] | [prev] | [next] | [standalone]

#18528

Hi Dimiter,

On 10/10/2014 2:18 PM, Dimiter_Popoff wrote:

>> 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.
>
> OK, I get that - in DPS this is the concept of runtime "objects",
> which have a 16 byte "name" but it is not for user consumption.

Exactly.  In my case, names are arbitrary length -- *like*
file names in a modern OS.  The cost of this is insignificant
as a process typically has a *small* namespace.  I.e., it
knows nothing of objects that it is NOT SUPPOSED TO ACCESS!

When the process tries to access ("open") an object, initially,
the process's namespace is the ONLY place that is examined
for the object name provided.  If a match is not found, there,
then the object does not exist (in the context of that process).

In other words, if you don't want a process to be able to access
an object, don't give the process any way of *referencing*
the object in the first place.

And, since the process's creator (parent) can only reference objects
that exist in *its* namespace, once you remove any references to an
object from one process's namespace, it is inaccessible by any of that
process's offspring!

There's no concept of a unified "global" namespace.  So, you're never
walking "long" paths from some "system root node".

> I use text in it but this is just a matter of convenience when

Exactly.  "stdout" is far more meaningful than "1299".  And, exactly
*what* that "stdout" is bound to (in some "global" sense) is immaterial.
A process never knows.

> I code. When the system searches for an object it just compares
> bytes (well longwords in reality, it does that with filenames
> too actually :-) ).
>
> But we were talking of a "file system", and in a file system
> one does have files which do have names some of which are created
> by humans and supposed to be read/memorized by humans.

The filesystem analogy is the only thing that "others" could relate to.
My namespaces are disjoint.  I.e., how does something running on one
of your netmca's reference an object on *another* netmca?  There's
no sense of "global naming" that each is aware of.

The "user" isn't creating objects (directly) in the same sense that
a user creates "files" in a "filesystem".  The user's *actions*
result in objects being created.  But, the user typically doesn't
know -- or care -- what these are called.

> At some
> level we do need the text for the name stored and searchable.
> If we just store the name text as bytes we end up needing
> twice the search overhead to do it case independent; which is
> why I think the unix makers back then left it case dependent,
> did not want to be bothered. It takes only a little - a bit
> per character - to do it the way it is done in DPS, and you
> have the best of both worlds. Case-free name information followed
> by the respective case bitstream. Somewhat more demanding to code but
> completely doable, was that for me anyway.
>
>>
>> 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).
>
> Well if you do not need to reproduce the names you get back you
> can simply hash the incoming names into what, 64 or may be just
> 32 bits and you are done. If you want to reproduce them forget
> it, just storing them as you got them is the only sensible way
> to go.

There are very few things that the user "injects" and may later
want to "remove".  I.e., few cases where the user needs to *pick* a
name -- and, later, remember it!

OTOH, there are places where the user (esp a developer-type)
may want to inquire as to what's happening at some place in
the system.  Having to remember that "1299" is the error log
for a particular process is tedious.  Easier to give the
process a unique name WHEN YOU DESIGNED IT and the error log
that *it* creates an equally recognizable name WITHIN THAT
CONTEXT so you can find it later without having to examine
the equivalent of a "link map".

> Which does not preclude you from "hashing" (in fact you can
> just use the addresses of the stored names or sort of) for your
> internal purposes, of course.

As namespaces tend to be small (consider how many objects one
of *your* processes encounters in its LIMITED scope of operation),
you can adopt simple schemes for maintaining "handles" on those
objects.

E.g., one of my OS structures carries a name that is identical to
it's location in memory!  Sure makes it easy to *find* it!  :>

>> 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?
>
> Oh come on Don, we all know the alphabet here, let's not go over
> it again.
>
>> 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.
>
> Yes, for the dps objects I wrote earlier about I do that sort of
> thing by making them do "listname" (or whatever the action was called).
> The plainest of objects just paste as text ("paste" at an address
> in memory, that is... :-) ) their 16 byte ID, more sophisticated
> ones which must be shown to the user have something better to paste
> (which may be static or not).
> But generally there is not much else you can do, if you need two
> different names for a thing you need two separate names, what can you
> do.

Yes.  In my case, a particular "physical" object (bad choice of words)
can have a bunch of names -- each different (or the same!) but in
different namespaces (even multiple references from within a single
reference!  e.g., stdout and stderr can resolve to the same
"physical" object -- which can only be accessed by *this* process
through these two names!)

> OTOH common file systems pose very little restrictions which will
> be in your way when you invent names during programming so I am
> not sure at all you have a real issue here.

Modern file systems impose naming constraints that are essentially
arbitrary.  Why can't I use '>' in a name?  Oh, because some
APPLICATION considers it a special symbol!  Why can't I use ' '
in a name?  Oh, because whitespace has historically delimited tokens.
Why does the file name have to be "short"?  Oh, because there is
an arbitrarly low limit on total pathname length and you never
know if some application (shell) will be called on to try to copy
that file to a point in the hierarchy that has a long path prefix.
(recall, each process in my world has it's own "root" node to its
private namespace).

Etc.

[toc] | [prev] | [next] | [standalone]

#18564

On 2014-10-10, Don Y <this@is.not.me.com> wrote:

> 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!

   Space, what space ? What do you do for U+00A0 and sisters ?
   http://en.wikipedia.org/wiki/Whitespace_character


-- 
   \_/°< coin        http://weblog.mixart-myrys.org/?post/2014/09/Radio-Myrys 

[toc] | [prev] | [next] | [standalone]

#18573

On 10/12/2014 1:07 PM, Tonton Th wrote:
> On 2014-10-10, Don Y <this@is.not.me.com> wrote:
>
>> 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!
>
>     Space, what space ? What do you do for U+00A0 and sisters ?
>     http://en.wikipedia.org/wiki/Whitespace_character

When you start attributing "meaning" to the symbols used to create
names -- and, thus, electing to impose "harmless transformations"
on them (case, etc.), you risk altering the intended "meaning"
(which only the originator of the identifier can define!).

Should U+24B6 and U+24D0 be treated as equivalent?  What about U+249C?
And *all* of U+00C0 thru U+00C5?  And U+00E0 thru U+00E5?  (and even more
"obvious" mappings elsewhere in the codeset)

For even wonkier ideas, should U+2801 and U+2809 be considered "equivalent"?
(why not?)  In UBC one could argue that they are.  Yet, if the creator had
intended this to be UEB, they would be VASTLY different!  (a vs c)

You can make translation maps for any set of symbols.  But, it seems to be
a lot more work and a lot less "robust" in interpretation...

[toc] | [prev] | [next] | [standalone]

#18520

Am 10.10.2014 um 19:53 schrieb Don Y:

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

And right there, the logic breaks down already.  There IS no such thing 
as "the object's own scope" when it comes to establishing a large-scale 
hierarchy of named things.  As much as that obviously rubs you the wrong 
way, one just HAS to make some allowances to keep the system working 
sensibly on a global scale, even if that limits the local subsystem's 
artistic freedom.

Otherwise how is anyone (or, equally important, any thing) to know 
whether, e.g.,

	foo\bar_baz

is a "foo\bar" with a "baz" in it, rather than a "foo" with a "bar_baz" 
in it, or even a "fo" containing an "o", which in turn contains a 
"bar_b" holding an "ar", without some global rule having set up that 
distinction aforehand?

In a nutshell: you can't have a hierarchy without clearly defined 
separators between levels.

Trying to avoid making such decisions on a global scale is not good 
design. It's actually the opposite: it's failure to design anything at all.

> 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.  :-/

The tricky question being what you count as a "capability".  There's 
about equally good grounds for calling it

a) a capability of Unix that it can actually store distinct files 
"Readme" and "README" in the same directory, and

b) a capability of Windows to find and open a file called "Readme" 
although your program actually misspelled that "README" in the open() call.

IMHO the Windows approach is just plain dumb silly.  It just makes no 
sense to store the case of file names if you're not going to do anything 
else with it, like, say, actually respect it as an identifying aspect of 
that filename.

And that's before you consider internationalizations.  How is, say, a 
German edition of Windows to know how Kyrillic or Greek letters map 
upper-case to lower-case letters?  And even if the system knows, why 
should it's user be expected to?

> OTOH, if you impose some restriction on the *basic* name scheme, you
> can never "enhance" it (without a lot of compatibility grief).

[toc] | [prev] | [next] | [standalone]

#18523

On 10.10.2014 г. 22:15, Hans-Bernhard Bröker wrote:
>...  It just makes no
> sense to store the case of file names if you're not going to do anything
> else with it, like, say, actually respect it as an identifying aspect of
> that filename.

Indeed, but storing a  name the way a user prefers to use capitals
in it or not means you don't lose that information - which the user
may want (usually does) to have preserved.
Capitalization in names serves indeed no other purpose than
appearance.
This is part of practically all languages so we have to be able to
reproduce it. OTOH, being lazy and just comparing bytes rather than
thinking a little beforehand how to lay out things so there is no
significant overhead involved with the case processing serves no
good purpose at all.

Dimiter

------------------------------------------------------
Dimiter Popoff, TGI             http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/

[toc] | [prev] | [next] | [standalone]

#18534

Dimiter_Popoff wrote:
> 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).

This will not work.

Do "i" and "I" name the same file? (In Turkish, the upper-case version
of "i" is "İ"; the lower-case version of "I" is "ı".)

Do "MASSE" and "Maße" name the same file? And what about "MASZE"? (In
German, the proper upper-case version of "ß" is "SS", with "SZ" being
allowed when it would otherwise be ambiguous; this being the case in the
example, where both "Masse" ("mass/weight") and "Maße" ("measurements/
dimensions") are proper words. An upper-case version of "ß" has been
recently introduced, but is not in wide use.)

The "I" ambiguity leads to a number of interesting bugs, such as this
one: <https://bugs.php.net/bug.php?id=35050>

I wouldn't want complex, environment-dependant code like that in any
system I have to depend on, such as a kernel or file system. We already
have it in mission-critical systems like the Domain Name System, and I'm
not entirely happy with that.


  Stefan

[toc] | [prev] | [next] | [standalone]

#18538

On 11.10.2014 г. 12:28, Stefan Reuther wrote:
> Dimiter_Popoff wrote:
>> 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).
>
> This will not work.

Well it has worked for quite some time already.

> Do "i" and "I" name the same file? (In Turkish, the upper-case version
> of "i" is "İ"; the lower-case version of "I" is "ı".)

Yes, I and i name the same file. No, I with two dots above it and I with
one dot do not, these are different characters.

> Do "MASSE" and "Maße" name the same file?

No, they do not.

> And what about "MASZE"? (In
> German,

Naming is not language specific, it is alphabet specific only.
Various languages may have various alphabets. I would of course
prefer if we all just used the Latin alphabet plain, as it is used
in English, but there is no problem at all with the capitalization
for its variations. So there is no problem storing the file case
information the right way. Then if you want to store some caseless
hieroglyphs you can do it by just leaving the case information
blank (e.g. in DPS you have up to 255 bytes for text and as many
bits for the corresponding case data).

Language processing is something else and has nothing to do with names.
Similar to the way we deal with a persons name, we do not translate
it but we do spell it correctly whenever the alphabet we use would
allow it.


> The "I" ambiguity leads to a number of interesting bugs, such as this
> one: <https://bugs.php.net/bug.php?id=35050>

There is no ambiguity at all in using the Latin alphabet. If one chooses
to introduce one he has to live with it. Your example is not related to
how we store and process case information.

>
> I wouldn't want complex, environment-dependant code like that in any
> system I have to depend on, such as a kernel or file system.


Like it or not file systems deal with files and files are named and the
names are for human consumption to a great part. So the way the names
are stored and searched for belongs there, together with the alphabet
rules which apply to reading/writing these names.

Dimiter

------------------------------------------------------
Dimiter Popoff, TGI             http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/

[toc] | [prev] | [next] | [standalone]

Page 1 of 5  [1] 2 3 4 5  Next page →

Back to top | Article view | comp.arch.embedded

csiph-web