Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #18514
| From | Don Y <this@is.not.me.com> |
|---|---|
| Newsgroups | comp.arch.embedded |
| Subject | Re: Filesystem syntax constraints under Windows |
| Date | 2014-10-10 10:34 -0700 |
| Organization | Aioe.org NNTP Server |
| Message-ID | <m195jb$bdl$1@speranza.aioe.org> (permalink) |
| References | <m18295$e3o$1@speranza.aioe.org> <m187i5$rav$1@speranza.aioe.org> <m18g3o$u4o$1@dont-email.me> <m18qdl$ckj$1@speranza.aioe.org> <m18u4t$8bk$1@dont-email.me> |
>>>>> 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, ...
>>> 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.
>
> In theory (I haven't tried this), you can create multiple files in an
> NTFS directory that differ only by case, because it is required for
> posix compatibility. But even on *nix systems, where this works
> perfectly well, it is not recommended practice because it can easily
> confuse people.
The user interface to the (NTFS) filesystem doesn't provide a mechanism
for doing so. E.g., creating "ReadMe" when "README" already exists doesn't
add another file (it simply overwrites the first one -- I think preserving
the original name, as well -- NOT the "new" filename!)
I will have to try it in an exported portion of an NTFS filesystem
accessed via NFS. Or, an NTFS filesystem under some other OS...
>>> 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]
>
> If I understand you correctly (I'm not sure I do fully - but that's okay
> for now), then I suspect your best idea is to restrict your names to
> plain English alphabet letters, assuming case-preservation but not
> case-sensitivity, with a few specific punctuation symbols. Treat "/" as
> a directory separator - it should work fine on almost any reasonable
> system.
That's the tail wagging dog approach. What I am trying to understand is
how Windows (and other OS's) parse pathnames -- where that functionality
resides. I.e., is it filesystem specific or embedded in the OS's notion
of "what comprises a pathname".
E.g., Windows recognizes // prefix for network shares. You can conceivably
argue that "ftp://" is just another part of the notion of a filesystem.
(In my case, I can create an object named "ftp://" at some particular point
in some particular namespace -- e.g., /my/personal/directory/ftp:// -- and
bind an "FTP resolver" to that "ftp://" object. Then, when any application
walks that path, entering the "ftp://" object causes *it* to parse the
balance of the pathname: /my/personal/directory/ftp://google.com/foobar)
I.e., parsing a pathname is expensive, for me -- because each "level"
requires invoking a "walk" method on a different object. But, it isn't
done often -- if you want to make walks quicker, create a second namespace
and bind the final entities (foobar in the above example) to nice short
names at the TOP of that namespace! The new namespace acts like a cache
of sorts.
*If* Windows passes the pathname for a given mount point to the "handler"
for that mounted filesystem and lets that handler resolve it, then I
should be free to map any characters into any functionality I want.
So, I can have:
traffic/10.0.1.23/inbound
traffic/fe80::1%lo0/outbound
etc. WITHOUT having to create some artificial naming scheme that maps
the "ideal" names into something that "Windows" can handle:
traffic/fe80__1&lo0
The whole point is to let each "object" define the rules for the names
of its components (or objects beneath it) in a manner that makes sense
in the context of the object.
E.g., if you treat "http://" as a top level object (an HTTP resolver),
then *it* applies whatever rules it deems appropriate to the objects
beneath it -- "host names". I.e., <hostname> is case insensitive.
A <hostname> object, in turn, defines the rules for objects beneath
it -- "host directories". I.e., <hostdir> is case SENSITIVE.
In the "traffic" example, the next level happens to allow names to be
bound to (things that look like) "IP addresses". So, the syntax allows
characters that you wouldn't encounter in Windows, etc.
> Punctuation that usually works without trouble is ".", "_", "-" and "+".
> Most other symbols will work in some circumstances, but can cause
> issues in particular cases (such as needed escapes or inverted commas
> when used from the command line).
> So if you want a namespace separator, without causing directory changes
> or other complications, pick one of "._-+".
I don't have a universal notion of a "separator". E.g., the above example
could just as easily have been:
traffic10.0.1.23inbound
trafficfe80::1%lo0outbound
[This can make for some interesting dilemmas if not used carefully! :>
But, I think it worth the cost to not reserve a delimiter at each level
in the hierarchy. So, you can have "foo" as a file coexisting alongside
"foo" as a folder -- in windows (i.e., the type of object effectively
adds another dimension to the identifier)]
Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll 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