Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #18498 > unrolled thread
| Started by | Don Y <this@is.not.me.com> |
|---|---|
| First post | 2014-10-10 00:31 -0700 |
| Last post | 2014-10-23 15:59 +0200 |
| Articles | 19 on this page of 99 — 10 participants |
Back to article view | Back to comp.arch.embedded
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 5 of 5 — ← Prev page 1 2 3 4 [5]
| From | Hans-Bernhard Bröker <HBBroeker@t-online.de> |
|---|---|
| Date | 2014-10-22 21:00 +0200 |
| Message-ID | <caqd5eF6i4gU1@mid.dfncis.de> |
| In reply to | #18873 |
Am 22.10.2014 um 01:27 schrieb glen herrmannsfeldt: > Well, there are more than one file systems used with Windows, and the > rules might be different. It's not the rules of the file systems that differ from each other. It's the rules of how other subsystems use the file system(s). The clue to the difference is that current NT-based Windows is actually a three-tier system: the Windows subsystem(s) on top of the NT kernel, on top of a hardware abstraction layer. File systems are part of the Kernel, and they're apparently required to be fully case-respecting. The silly "case-preserving, but not case-sensitive" behaviour must be implemented on top of that, by the Windows subsystem. The "Interix" tools Don Y talks about live in an alternative subsystem, distinct from Windows itself, that works directly with the kernel. So Interix can indeed use the same file systems, but do it differently than the Windows subsystem. > For NTFS, I believe the longer names are really part of the file > system and directory, not quite the same as for FAT. The difference isn't really that big. For reasons of compatibility, even NTFS directories have to maintain 8.3-format alias names for all entries whose names don't match that format. > It might be > that NTFS can still supply a short name for programs that require > them. It can't just supply one, it has to pick an 8.3 alias name at file creation time, and _store_ it along with the "real" one, because that alias has to remain unchanged for as long as the entry exists. Some truly braindead installers even presume that the path to their installation directory must "of course" be below "c:\progra~1", (just to avoid having to evaluate %ProgramFiles%).
[toc] | [prev] | [next] | [standalone]
| From | upsidedown@downunder.com |
|---|---|
| Date | 2014-10-22 22:54 +0300 |
| Message-ID | <n12g4ap9ggbq3gglkrq4jmdbcm98gqvmoo@4ax.com> |
| In reply to | #18898 |
On Wed, 22 Oct 2014 21:00:03 +0200, Hans-Bernhard Bröker <HBBroeker@t-online.de> wrote: >Am 22.10.2014 um 01:27 schrieb glen herrmannsfeldt: > >> Well, there are more than one file systems used with Windows, and the >> rules might be different. > >It's not the rules of the file systems that differ from each other. >It's the rules of how other subsystems use the file system(s). > >The clue to the difference is that current NT-based Windows is actually >a three-tier system: the Windows subsystem(s) on top of the NT kernel, >on top of a hardware abstraction layer. > >File systems are part of the Kernel, and they're apparently required to >be fully case-respecting. The silly "case-preserving, but not >case-sensitive" behaviour must be implemented on top of that, by the >Windows subsystem. > >The "Interix" tools Don Y talks about live in an alternative subsystem, >distinct from Windows itself, that works directly with the kernel. So >Interix can indeed use the same file systems, but do it differently than >the Windows subsystem. > >> For NTFS, I believe the longer names are really part of the file >> system and directory, not quite the same as for FAT. > >The difference isn't really that big. For reasons of compatibility, >even NTFS directories have to maintain 8.3-format alias names for all >entries whose names don't match that format. > >> It might be >> that NTFS can still supply a short name for programs that require >> them. > >It can't just supply one, it has to pick an 8.3 alias name at file >creation time, and _store_ it along with the "real" one, because that >alias has to remain unchanged for as long as the entry exists. > >Some truly braindead installers even presume that the path to their >installation directory must "of course" be below "c:\progra~1", (just >to avoid having to evaluate %ProgramFiles%). I still do not understand what this thread is all about. If the intention is to mount foreign file systems directly (local drive) or over the network, you really have to use features that all systems support. There is not much point of trying to map the most awkward features of each system to every other file system. Some Linux based systems support Unicode file names in UTF-8, while Windows NTFS is UTF-16 based (but the supported characters might be different), while some Unix systems are Latin-1 based or just supporting 7 bit ASCII (upper and lower case). Some older 6 bit systems only supported upper case letters or just 40 symbols. IMHO, it is pointless to try to make very special mappings. In order to co-operate, you really have to forget any "purity" claims and try to find what is common in different systems.
[toc] | [prev] | [next] | [standalone]
| From | Dimiter_Popoff <dp@tgi-sci.com> |
|---|---|
| Date | 2014-10-22 02:32 +0300 |
| Message-ID | <m26qd9$min$1@dont-email.me> |
| In reply to | #18872 |
Hi Don, On 22.10.2014 г. 01:51, Don Y wrote: > ... > > Under Interix, you bypass Windows' rules for names and write directly to > the file system (disk media). Well writing to a directory entry not through a system call would easily break the directory, sure. I don't have to tell you this is not the way you want to go in an end product (instability, impredictability issues - how will the next OS version treat these invalid entries etc. etc.). > So, "touch AaA" creates a file called "AaA" while "touch aaa" creates > ANOTHER file -- called "aaa". Windows Explorer is smart enough (dumb > enough?) to display these as separate files. That's not surprising, once you trick the filesystem with an invalid name entry it will not try to do much on it. When it lists a directory it will just go through all the entries and list. > ... And, will know which > one to "open" if I select it with mouse. That is more surprising to me. It means they go through some sideways to locate the clicked file, not by searching for it by name. In DPS, this could be done by using DEN (directory entry number, well it is not a number but pool_no:cluster really), i.e. you list the names on the menu, then for each menu entry you store the DEN and access the file subsequently based on that (possible but impractical). Or you can just keep all the files on the menu open and access not by name but by "registration" (i.e. "handle"). >> If you want to copy files with duplicate names (i.e. coming from a >> unix filesystem) the only correct way is to rename the file(s), e.g. >> by appending some unique sequential number or sort of. > > This is exactly the problem I encounter when trying to "manage" > large file collections that originate in UN*X *under* Windows. Well I figured as much in the meantime :D . That was the underlying reason for your initial post I suppose. > E.g., Makefile and makefile collide in Windows' namespace. So, > I end up with one or the other (depends on which order they are > REcreated). > ..... > Bottom line, Windows is an annoyance. It probably is much worse than an annoyance to program under but in the example above I would point the finger at the person who has been shortsighted enough to create duplicate file names in the unix environment first, then on the way the unix filesystem is made to allow duplicate file names being created by users. I don't see how you can handle this situation without inserting a complete name handling layer between. For example, this is what I did in a similar situation - when one wants to copy * from a longnamed directory into a shortnamed (old, 8.4) one. Files get copied by just using the first up to 8 characters and up to 4 past the last "." character; if such a name has been used already creation will fail (duplicate file name) and the copy code before retrying will modify the destination name by replacing the last 4 name characters (I think) by the text hex. representation of a counter which gets incremented every time it is used. No other way around it, you either have to maintain the file name data case dependent (human readable) or case independent (in that case 8 bytes per file would be plenty). Some bridging between these two fundamentally different cases will always be necessary if they have to coexist. Dimiter ------------------------------------------------------ Dimiter Popoff, TGI http://www.tgi-sci.com ------------------------------------------------------ http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
[toc] | [prev] | [next] | [standalone]
| From | Don Y <this@is.not.me.com> |
|---|---|
| Date | 2014-10-21 17:21 -0700 |
| Message-ID | <m26t9v$cb0$1@speranza.aioe.org> |
| In reply to | #18874 |
Hi Dimiter, On 10/21/2014 4:32 PM, Dimiter_Popoff wrote: > On 22.10.2014 г. 01:51, Don Y wrote: >> ... >> >> Under Interix, you bypass Windows' rules for names and write directly to >> the file system (disk media). > > Well writing to a directory entry not through a system call would > easily break the directory, sure. I don't have to tell you this > is not the way you want to go in an end product (instability, > impredictability issues - how will the next OS version treat > these invalid entries etc. etc.). But there is no evidence that this is the case! I.e., I suspect the Interix subsystem doesn't do "raw I/O". Rather, uses a lower level interface to the medium than the "GUI" OS does. Recall, original DOS treated all filenames as singlecase. So, "AaA" was not accessible. <http://support.microsoft.com/kb/100625> >> So, "touch AaA" creates a file called "AaA" while "touch aaa" creates >> ANOTHER file -- called "aaa". Windows Explorer is smart enough (dumb >> enough?) to display these as separate files. > > That's not surprising, once you trick the filesystem with an invalid > name entry it will not try to do much on it. When it lists a directory > it will just go through all the entries and list. But, that's NOT the case in Windows! :> E.g., Windows Explorer did not list the folder/directory contents the same way that the Interix subsystem did. And, from a DOS box, "DIR" performed silent translations on the file names! E.g., "C*c" appears AS "C*c" on the actual volume. Interix displays its name as "C*c". The DIR command displays it as "C?c". And, Windows Explorer displays it as "Cc". I.e., they are implementing special case processing even when the file name already exists (instead of just treating it as is!) >> ... And, will know which >> one to "open" if I select it with mouse. > > That is more surprising to me. It means they go through some sideways > to locate the clicked file, not by searching for it by name. I assume the GUI code that displays a folder is given a list of names to display. When you click on a name (via mouse), it looks at cursor's (x,y) and maps that to a particular "line of text" in the display. Then, passes a pointer to "list entry number X" as the result of the "selection". > In DPS, this could be done by using DEN (directory entry number, well > it is not a number but pool_no:cluster really), i.e. > you list the names on the menu, then for each menu entry you store > the DEN and access the file subsequently based on that (possible > but impractical). > Or you can just keep all the files on the menu open and access not by > name but by "registration" (i.e. "handle"). > >>> If you want to copy files with duplicate names (i.e. coming from a >>> unix filesystem) the only correct way is to rename the file(s), e.g. >>> by appending some unique sequential number or sort of. >> >> This is exactly the problem I encounter when trying to "manage" >> large file collections that originate in UN*X *under* Windows. > > Well I figured as much in the meantime :D . That was the underlying > reason for your initial post I suppose. Only indirectly. I wanted to know what I could "get away with" in mapping my "names" to other contexts (e.g., Windows). I, for example, don't reserve '/' (or '\') as path separators. Or '>' as a reserved shell redirection operator (artificially prohibiting it in a filename). Or, ':' to indicate legacy "devices" (COM1:). So, I could have names like: Class::Member I/O READ/write ---> <--- etc. >> E.g., Makefile and makefile collide in Windows' namespace. So, >> I end up with one or the other (depends on which order they are >> REcreated). >> ..... >> Bottom line, Windows is an annoyance. > > It probably is much worse than an annoyance to program under but > in the example above I would point the finger at the person who > has been shortsighted enough to create duplicate file names in > the unix environment first, then on the way the unix filesystem > is made to allow duplicate file names being created by users. But it is not "shortsighted" -- especially as UNIX predated ALL of MS's offerings! Again, recall that I'm using these as "object names", not FILE names. So, they are created by a developer and hide *inside* sources. If, for example, process A creates an object and calls it "Fred", it is perfectly reasonable to expect consumers of that object to refer to it as "Fred" -- and not "fred", "FrEd", "fRED" or "Bob"! E.g., a service can elect to name it's CURRENT clients using a template like "client##". If that service later tried to resolve "ClIeNt23", it seems reasonable (nay, desireable!) that this name should NOT resolve (Gee, can't you remember what you called this client a few microseconds ago??) > I don't see how you can handle this situation without inserting > a complete name handling layer between. I don't tolerate any deviation from that which was originally specified (*within* my system). "Say what you mean and mean what you say". Dealing with "foreign systems" (e.g., Windows) is the only issue because it/they are inflexible in their naming conventions. :< But, I can accommodate them by just planning on creating an exported namespace *intended* for their use. E.g., if I want to make the object named "I/O" accessible, I can create a namespace in which "io_device" is mapped to the same object as *my* "I/O". If the foreign system can't handle lowercase characters, I can create a different namespace wherein "IO_DEVICE" maps to my "I/O". Or, "IO$DEVICE" for VAX fans... If Windows (it's GUI) wants to treat "Io_DeViCe" as an alternate name for the "io_device" that I export, then so be it. I just have to have a "method" that fabricates viable names for exported objects and have that method vary with the foreign system involved. > For example, this is what I did in a similar situation - when one > wants to copy * from a longnamed directory into a shortnamed > (old, 8.4) one. > Files get copied by just using the first up to 8 characters and > up to 4 past the last "." character; if such a name has been > used already creation will fail (duplicate file name) and the copy > code before retrying will modify the destination name by replacing > the last 4 name characters (I think) by the text hex. representation > of a counter which gets incremented every time it is used. > No other way around it, you either have to maintain the file name > data case dependent (human readable) or case independent (in that > case 8 bytes per file would be plenty). Some bridging between > these two fundamentally different cases will always be necessary > if they have to coexist.
[toc] | [prev] | [next] | [standalone]
| From | Dimiter_Popoff <dp@tgi-sci.com> |
|---|---|
| Date | 2014-10-22 03:52 +0300 |
| Message-ID | <m26v45$2pe$1@dont-email.me> |
| In reply to | #18877 |
Hi Don, On 22.10.2014 г. 03:21, Don Y wrote: > ...... >> >> That's not surprising, once you trick the filesystem with an invalid >> name entry it will not try to do much on it. When it lists a directory >> it will just go through all the entries and list. > > But, that's NOT the case in Windows! :> > > E.g., Windows Explorer did not list the folder/directory contents > the same way that the Interix subsystem did. And, from a DOS box, > "DIR" performed silent translations on the file names! > > E.g., "C*c" appears AS "C*c" on the actual volume. Interix displays > its name as "C*c". The DIR command displays it as "C?c". And, > Windows Explorer displays it as "Cc". > > I.e., they are implementing special case processing even when the > file name already exists (instead of just treating it as is!) Ouch. Well, this is as huge an ouch as they likely make them. The only practical way out of this I see is to restrict the file names you let windows handle to the subset they handle consistently, the rest of the effort will be a (potentially huge) waste of time & effort. Even if you somehow manage to cover for all cases your solution will work only until their next version or even revision. > ... >>> E.g., Makefile and makefile collide in Windows' namespace. So, >>> I end up with one or the other (depends on which order they are >>> REcreated). >>> ..... >>> Bottom line, Windows is an annoyance. >> >> It probably is much worse than an annoyance to program under but >> in the example above I would point the finger at the person who >> has been shortsighted enough to create duplicate file names in >> the unix environment first, then on the way the unix filesystem >> is made to allow duplicate file names being created by users. > > But it is not "shortsighted" -- especially as UNIX predated > ALL of MS's offerings! Uhm, relying on a character case you type in to have a different file name is nothing I would cann otherwise :-). I can easily see how a programmer can be tempted to do so in a quick hack but it is similar to patching object code in hex without changing the source code "just this once to see what happens". Things like that are bound to bite back, who of us has not been bitten. (Actually I still do patch code sometimes like that but rarely and I must have become better at being cautious enough not to get bitten... or used to the bites and not even noticing them :D ). > Again, recall that I'm using these as "object names", not FILE names. I get that, so you are absolutely fine with say 64 bits per object ID (strictly it is not a "name", names are written in text and text at its basic level is case independent). But you just cannot feed binary data into something expecting text as an input and hope things would work, you will have to put a translation layer between the two. I just don't see any way around it. Say a file in your directory mapping all your 64 bit entries into text names or something. Dimiter ------------------------------------------------------ Dimiter Popoff, TGI http://www.tgi-sci.com ------------------------------------------------------ http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
[toc] | [prev] | [next] | [standalone]
| From | Don Y <this@is.not.me.com> |
|---|---|
| Date | 2014-10-21 21:13 -0700 |
| Message-ID | <m27atp$4dn$1@speranza.aioe.org> |
| In reply to | #18880 |
Hi Dimiter,
On 10/21/2014 5:52 PM, Dimiter_Popoff wrote:
>> Again, recall that I'm using these as "object names", not FILE names.
>
> I get that, so you are absolutely fine with say 64 bits per object ID
> (strictly it is not a "name", names are written in text and text
> at its basic level is case independent).
> But you just cannot feed binary data into something expecting
> text as an input and hope things would work, you will
> have to put a translation layer between the two. I just don't see
> any way around it. Say a file in your directory mapping all your
> 64 bit entries into text names or something.
I treat names as "arbitrary length, 0x00-terminated "byte arrays/strings".
The whole point is to leave things up to the developer/object-implementer
to decide what constitutes a "good name".
E.g., one might choose {0x01,0x00}, {0x02,0x00}, {0x03, 0x00}...
while someone else might choose I_Like_Insanely_Long_Names_1,
I_Like_Insanely_Long_Names_2, etc.
In this way, someone could choose to encode information in a particular
name "template" and select from among the available objects in his
namespace based on some criteria that maps easily to the template he
has chosen:
Client_Local_1_Priority_B
Client_Local_5_Priority_A
Client_Local_7_Priority_B
Client_Remote_2_Priority_B
Client_Remote_8_Priority_C
etc. So, he can choose to select from among the "Client_Local_*" objects.
Or, the "*_Priority_A" objects, etc.
The entity that binds the names to the objects decides what is important
to it (or, to it's offspring as the initial bindings come from the parent
spawning the process). *It* decides what sort of overhead it wants to
support/incur.
Also, namespaces *tend* to be small. With how many "objects" does one of your
processes typically interact? The whole point is to *ONLY* expose the objects
that a process NEEDS to access *to* that process. Hide everything that it
should NOT be mucking with by simply not providing a *name* for those objects
that shouldn't be accessible!
(If you can't provide a name to the "System" by which it can locate the
object for you -- based on the contents of the namespace that *it*
maintains on your behalf -- then there is no way for you to access or operate
on that object!)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2014-10-22 08:10 +0200 |
| Message-ID | <m27hov$7ks$1@dont-email.me> |
| In reply to | #18874 |
On 22/10/14 01:32, Dimiter_Popoff wrote:
> Hi Don,
>
> On 22.10.2014 г. 01:51, Don Y wrote:
>> ...
>>
>> Under Interix, you bypass Windows' rules for names and write directly to
>> the file system (disk media).
>
> Well writing to a directory entry not through a system call would
> easily break the directory, sure. I don't have to tell you this
> is not the way you want to go in an end product (instability,
> impredictability issues - how will the next OS version treat
> these invalid entries etc. etc.).
>
He is not hacking the disk in some way - he is using Interix, which is
written by Microsoft as sort of mostly Posix compatibility layer for
Windows. This layer does not use the Win32 API, but it uses the NT
kernel services and system calls in the same way that the Win32 API
does. Thus is uses posix-compatible API's to ask the Windows VFS system
to create, read or write files, and the VFS system passes this on to the
NTFS system. When using explorer, the code uses thw Win32 API to talk
to the VFS and then on to the NTFS.
What we are seeing here is that the NTFS filesystem is perfectly capable
of holding filenames with almost arbitrary characters, and does not do
any case-dependent handling (thus "a" and "A" are different characters,
and can be different filenames). This is not surprising, since NTFS was
designed to be usable in a Posix environment, and also since it uses a
restricted UTF-16 (no multi-point characters) for filenames and does not
attempt to include the vast set of rules needed to handle case dependencies.
We also see that through Interix, filenames are not mangled, except
perhaps to handle "/" as a directory separator. Through the Win32 API,
filenames are mangled in a variety of ways both going into the VFS, and
coming out of it - and can be mangled in different ways depending on the
particular calls being used. They are then further mangled by the
application ("explorer.exe", "cmd.exe", etc.). This is no surprise
either, given the history of the system which attempts to remain
somewhat compatible with a range of different limitations in kernels and
filesystems DOS, Win9x, NT, FAT, FAT32, etc.
And since the mangling and translations are done at different stages -
some in the APIs, some in the applications, some in the libraries -
there is repetition and inconsistencies. This is also no surprise,
based on the development environment at MS - different groups handle
different parts, but act competitively rather than cooperatively, with
an appalling lack of documentation or references.
[toc] | [prev] | [next] | [standalone]
| From | Dimiter_Popoff <dp@tgi-sci.com> |
|---|---|
| Date | 2014-10-22 12:00 +0300 |
| Message-ID | <m27rng$4am$1@dont-email.me> |
| In reply to | #18883 |
On 22.10.2014 г. 09:10, David Brown wrote:
> On 22/10/14 01:32, Dimiter_Popoff wrote:
>> Hi Don,
>>
>> On 22.10.2014 г. 01:51, Don Y wrote:
>>> ...
>>>
>>> Under Interix, you bypass Windows' rules for names and write directly to
>>> the file system (disk media).
>>
>> Well writing to a directory entry not through a system call would
>> easily break the directory, sure. I don't have to tell you this
>> is not the way you want to go in an end product (instability,
>> impredictability issues - how will the next OS version treat
>> these invalid entries etc. etc.).
>>
>
> He is not hacking the disk in some way - he is using Interix, which is
> written by Microsoft as sort of mostly Posix compatibility layer for
> Windows. This layer does not use the Win32 API, but it uses the NT
> kernel services and system calls in the same way that the Win32 API
> does. Thus is uses posix-compatible API's to ask the Windows VFS system
> to create, read or write files, and the VFS system passes this on to the
> NTFS system. When using explorer, the code uses thw Win32 API to talk
> to the VFS and then on to the NTFS.
>
> What we are seeing here is that the NTFS filesystem is perfectly capable
> of holding filenames with almost arbitrary characters, and does not do
> any case-dependent handling (thus "a" and "A" are different characters,
> and can be different filenames). This is not surprising, since NTFS was
> designed to be usable in a Posix environment, and also since it uses a
> restricted UTF-16 (no multi-point characters) for filenames and does not
> attempt to include the vast set of rules needed to handle case
> dependencies.
>
> We also see that through Interix, filenames are not mangled, except
> perhaps to handle "/" as a directory separator. Through the Win32 API,
> filenames are mangled in a variety of ways both going into the VFS, and
> coming out of it - and can be mangled in different ways depending on the
> particular calls being used. They are then further mangled by the
> application ("explorer.exe", "cmd.exe", etc.). This is no surprise
> either, given the history of the system which attempts to remain
> somewhat compatible with a range of different limitations in kernels and
> filesystems DOS, Win9x, NT, FAT, FAT32, etc.
>
> And since the mangling and translations are done at different stages -
> some in the APIs, some in the applications, some in the libraries -
> there is repetition and inconsistencies. This is also no surprise,
> based on the development environment at MS - different groups handle
> different parts, but act competitively rather than cooperatively, with
> an appalling lack of documentation or references.
>
David, I am not sure what you are trying to explain but I do not think
there are many people here who need to be told that a set of characters
stored as bytes can be compared in a case dependent or independent
manner.
Key to the point is:
1. The filesystem stores all name related data it is given (i.e. without
loss of information),
2. The user is not exposed to the bitstreams the OS stores but to to
text which consists of characters which are part of an alphabet,
for example the Latin alphabet as used in English has 26 characters.
Don's problem is that he just cannot copy a unix directory if it
contains duplicate file names to an NTFS one such that it is usable.
Of course he can hack his way into doing it, whether through some
MS written hack which you say is not a hack or otherwise.
The problem remains and will remain, as unix does
not output names but file identifiers (names consist of text, remember
the alphabet and the character count). The fact that these identifiers
have been misused as text for decades does not mean much beyond
the expectations of hardcore unix users that the English alphabet
will suddenly begin to have 52 characters.
What exactly are you trying to prove, why do you keep on flailing.
Why is it so hard for you to accept that you have overlooked a few
simple, obvious facts and just move on.
Dimiter
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2014-10-22 13:11 +0200 |
| Message-ID | <m283df$s7t$1@dont-email.me> |
| In reply to | #18885 |
On 22/10/14 11:00, Dimiter_Popoff wrote:
> On 22.10.2014 г. 09:10, David Brown wrote:
>> On 22/10/14 01:32, Dimiter_Popoff wrote:
>>> Hi Don,
>>>
>>> On 22.10.2014 г. 01:51, Don Y wrote:
>>>> ...
>>>>
>>>> Under Interix, you bypass Windows' rules for names and write
>>>> directly to
>>>> the file system (disk media).
>>>
>>> Well writing to a directory entry not through a system call would
>>> easily break the directory, sure. I don't have to tell you this
>>> is not the way you want to go in an end product (instability,
>>> impredictability issues - how will the next OS version treat
>>> these invalid entries etc. etc.).
>>>
>>
>> He is not hacking the disk in some way - he is using Interix, which is
>> written by Microsoft as sort of mostly Posix compatibility layer for
>> Windows. This layer does not use the Win32 API, but it uses the NT
>> kernel services and system calls in the same way that the Win32 API
>> does. Thus is uses posix-compatible API's to ask the Windows VFS system
>> to create, read or write files, and the VFS system passes this on to the
>> NTFS system. When using explorer, the code uses thw Win32 API to talk
>> to the VFS and then on to the NTFS.
>>
>> What we are seeing here is that the NTFS filesystem is perfectly capable
>> of holding filenames with almost arbitrary characters, and does not do
>> any case-dependent handling (thus "a" and "A" are different characters,
>> and can be different filenames). This is not surprising, since NTFS was
>> designed to be usable in a Posix environment, and also since it uses a
>> restricted UTF-16 (no multi-point characters) for filenames and does not
>> attempt to include the vast set of rules needed to handle case
>> dependencies.
>>
>> We also see that through Interix, filenames are not mangled, except
>> perhaps to handle "/" as a directory separator. Through the Win32 API,
>> filenames are mangled in a variety of ways both going into the VFS, and
>> coming out of it - and can be mangled in different ways depending on the
>> particular calls being used. They are then further mangled by the
>> application ("explorer.exe", "cmd.exe", etc.). This is no surprise
>> either, given the history of the system which attempts to remain
>> somewhat compatible with a range of different limitations in kernels and
>> filesystems DOS, Win9x, NT, FAT, FAT32, etc.
>>
>> And since the mangling and translations are done at different stages -
>> some in the APIs, some in the applications, some in the libraries -
>> there is repetition and inconsistencies. This is also no surprise,
>> based on the development environment at MS - different groups handle
>> different parts, but act competitively rather than cooperatively, with
>> an appalling lack of documentation or references.
>>
>
> David, I am not sure what you are trying to explain but I do not think
> there are many people here who need to be told that a set of characters
> stored as bytes can be compared in a case dependent or independent
> manner.
I am trying to explain that Don is not doing something odd or outside of
the windows system here, as you seemed to think:
>>> Well writing to a directory entry not through a system call would
>>> easily break the directory, sure.
If he had used a disk editor to directly change the filenames, then I
could understand your comment. But he has not done anything like that -
he has used programs written by Microsoft to run on Windows, and used
them to create filenames that other parts of Windows can't deal with
properly.
> Key to the point is:
> 1. The filesystem stores all name related data it is given (i.e. without
> loss of information),
Yes...
> 2. The user is not exposed to the bitstreams the OS stores but to to
> text which consists of characters which are part of an alphabet,
> for example the Latin alphabet as used in English has 26 characters.
In other words, Windows mangles the names it is given.
>
> Don's problem is that he just cannot copy a unix directory if it
> contains duplicate file names to an NTFS one such that it is usable.
That is one of his problems, yes.
> Of course he can hack his way into doing it, whether through some
> MS written hack which you say is not a hack or otherwise.
The Win32 API allows files to be created or opened using "posix
semantics" for filenames, including case-sensitive files, characters
such as ":" and "*" in filenames, and multiple files differing only in
the case of their names. Even if you want to call the MS-supplied posix
compatibility layer a "hack", I don't think the standard Win32 API is a
hack.
>
> The problem remains and will remain, as unix does
> not output names but file identifiers (names consist of text, remember
> the alphabet and the character count). The fact that these identifiers
> have been misused as text for decades does not mean much beyond
> the expectations of hardcore unix users that the English alphabet
> will suddenly begin to have 52 characters.
This goes back to your unique idea that files have a sort of colloquial
human-friendly nick-name that is a different concept from their
"filename" that everyone else uses.
If we were to accept that idea, then /all/ systems have that "problem" -
because no system will be happy with a file system that uses approximate
names instead of concrete identifiers. By that I mean that
"index.html", "Index.html", "Index.html", "Index", "The index file", and
"The first page" are perfectly good human-friendly names for the first
page of a website - but no OS or filesystem would accept them as
alternatives for a file identified as "index.html".
>
> What exactly are you trying to prove, why do you keep on flailing.
> Why is it so hard for you to accept that you have overlooked a few
> simple, obvious facts and just move on.
>
I am just trying to correct your (apparent) misunderstanding about what
Don was doing, and how Windows and NTFS treat filenames.
[toc] | [prev] | [next] | [standalone]
| From | Dimiter_Popoff <dp@tgi-sci.com> |
|---|---|
| Date | 2014-10-22 15:19 +0300 |
| Message-ID | <m287d3$9jg$1@dont-email.me> |
| In reply to | #18886 |
On 22.10.2014 г. 14:11, David Brown wrote: > >> 2. The user is not exposed to the bitstreams the OS stores but to to >> text which consists of characters which are part of an alphabet, >> for example the Latin alphabet as used in English has 26 characters. > > In other words, Windows mangles the names it is given. No. It reproduces the names exactly as the user has entered them. >> Of course he can hack his way into doing it, whether through some >> MS written hack which you say is not a hack or otherwise. > > The Win32 API allows files to be created or opened using "posix > semantics" for filenames, including case-sensitive files, characters > such as ":" and "*" in filenames, and multiple files differing only in > the case of their names. Even if you want to call the MS-supplied posix > compatibility layer a "hack", I don't think the standard Win32 API is a > hack. You may think whatever you want but using a low enough level call to create invalid directory entries is a hack, whoever may have written the code within the system call. Non-hack application code does not go that low in order to defeat the system-wide rules or compromise the system in other ways, there are always plenty of opportunities to kill a system. >> The problem remains and will remain, as unix does >> not output names but file identifiers (names consist of text, remember >> the alphabet and the character count). The fact that these identifiers >> have been misused as text for decades does not mean much beyond >> the expectations of hardcore unix users that the English alphabet >> will suddenly begin to have 52 characters. > > This goes back to your unique idea that files have a sort of colloquial > human-friendly nick-name that is a different concept from their > "filename" that everyone else uses. Blimey, so it is my unique idea that file names are meant also for human consumption/processing. Are you sure you are in good health? > > If we were to accept that idea, then /all/ systems have that "problem" - > because no system will be happy with a file system that uses approximate > names instead of concrete identifiers. By that I mean that > "index.html", "Index.html", "Index.html", "Index", "The index file", and > "The first page" are perfectly good human-friendly names for the first > page of a website - but no OS or filesystem would accept them as > alternatives for a file identified as "index.html". And you go further down the path into demonstrating that you are just flailing madly being unable to accept the simple fact that you said something stupid (can happen to everyone) and then defend that for days and days (does not happen to everyone). > I am just trying to correct your (apparent) misunderstanding about what > Don was doing, and how Windows and NTFS treat filenames. Yeah, you always know better than everyone, I know. Never mind you have no clue what we are talking about really. Dimiter
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2014-10-22 15:21 +0200 |
| Message-ID | <m28b18$mq4$1@dont-email.me> |
| In reply to | #18888 |
On 22/10/14 14:19, Dimiter_Popoff wrote: > On 22.10.2014 г. 14:11, David Brown wrote: > >> >>> 2. The user is not exposed to the bitstreams the OS stores but to to >>> text which consists of characters which are part of an alphabet, >>> for example the Latin alphabet as used in English has 26 characters. >> >> In other words, Windows mangles the names it is given. > > No. It reproduces the names exactly as the user has entered them. > Don entered filenames, albeit unusual ones. These filenames were perfectly valid for the filesystem (NTFS), they were perfectly valid for the OS itself (Windows), and they were perfectly valid for the programs used to enter those names. But they got mangled by other parts of the key Windows software when he viewed them. Do you mean that because "a*b" has a non-letter, it is not a valid name? Or do you mean that Don doesn't count as a "user" because he is using filenames that you don't like? >>> Of course he can hack his way into doing it, whether through some >>> MS written hack which you say is not a hack or otherwise. >> >> The Win32 API allows files to be created or opened using "posix >> semantics" for filenames, including case-sensitive files, characters >> such as ":" and "*" in filenames, and multiple files differing only in >> the case of their names. Even if you want to call the MS-supplied posix >> compatibility layer a "hack", I don't think the standard Win32 API is a >> hack. > > You may think whatever you want but using a low enough level call to > create invalid directory entries is a hack, whoever may have written > the code within the system call. > Non-hack application code does not go that low in order to defeat the > system-wide rules or compromise the system in other ways, there are > always plenty of opportunities to kill a system. We are talking about the Win32 API "CreateFile" call here! This is how you create files in Windows programming. If that is a "hack", then /all/ windows programming is a "hack". > >>> The problem remains and will remain, as unix does >>> not output names but file identifiers (names consist of text, remember >>> the alphabet and the character count). The fact that these identifiers >>> have been misused as text for decades does not mean much beyond >>> the expectations of hardcore unix users that the English alphabet >>> will suddenly begin to have 52 characters. >> >> This goes back to your unique idea that files have a sort of colloquial >> human-friendly nick-name that is a different concept from their >> "filename" that everyone else uses. > > Blimey, so it is my unique idea that file names are meant also for human > consumption/processing. No, it is your unique idea that an OS has to treat filenames using human language rules because they are always for human processing and consumption - and it is your unique idea to distinguish between a "file name" and a "file identifier", where a "file name" is case insensitive and human friendly, while a "file identifier" can store the case and use other characters. > > Are you sure you are in good health? Please try to cut down on the insults or implied insults - this is a friendly technical discussion, not a name-calling contest. > >> >> If we were to accept that idea, then /all/ systems have that "problem" - >> because no system will be happy with a file system that uses approximate >> names instead of concrete identifiers. By that I mean that >> "index.html", "Index.html", "Index.html", "Index", "The index file", and >> "The first page" are perfectly good human-friendly names for the first >> page of a website - but no OS or filesystem would accept them as >> alternatives for a file identified as "index.html". > > And you go further down the path into demonstrating that you are just > flailing madly being unable to accept the simple fact that you said > something stupid (can happen to everyone) and then defend that for > days and days (does not happen to everyone). I agree that everyone says stupid things once in a while, especially on Usenet - I have done so often enough, and when I realise it, I have posted apologies or thanks as follow-ups. I - and others - have completely disagreed with you concerning filenames and case sensitivity. From where I stand, you came up with some unusual claims that are at odds to the rest of the world of filesystem and OS design, and have repeatedly labelled these as "obvious facts" while denying all the counter-evidence presented. Your argument boiled down to accusing others of religious delusions. Look back in this thread if you don't remember the details. (For your own OS, I assume that /your/ way of treating file names is the most suitable for the OS and its uses. That's fine. What I object to is your belief that it should apply to every OS, that other OS'es are fundamentally flawed because of their treatment of filenames, and that everyone else is "stupid" or "religious" for disagreeing with you.) > >> I am just trying to correct your (apparent) misunderstanding about what >> Don was doing, and how Windows and NTFS treat filenames. > > Yeah, you always know better than everyone, I know. > Never mind you have no clue what we are talking about really. > Some things I know, some things I learn. That's because I don't extrapolate the way /I/ do something to assuming it is the only right way to do it.
[toc] | [prev] | [next] | [standalone]
| From | Dimiter_Popoff <dp@tgi-sci.com> |
|---|---|
| Date | 2014-10-22 17:26 +0300 |
| Message-ID | <m28er3$4ml$1@dont-email.me> |
| In reply to | #18889 |
On 22.10.2014 г. 16:21, David Brown wrote: > On 22/10/14 14:19, Dimiter_Popoff wrote: >> On 22.10.2014 г. 14:11, David Brown wrote: >> >>> >>>> 2. The user is not exposed to the bitstreams the OS stores but to to >>>> text which consists of characters which are part of an alphabet, >>>> for example the Latin alphabet as used in English has 26 characters. >>> >>> In other words, Windows mangles the names it is given. >> >> No. It reproduces the names exactly as the user has entered them. >> > > Don entered filenames, ... No, he wrote a program to squeeze these names through the system. A user cannot enter names the system does not allow to be entered. > Do you mean that because "a*b" has a non-letter, it is not a valid name? It might be, "*" is typically a reserved symbol for communication between the user interface and the directory search code. If the user interface won't let you do it chances are it is illegal. If you don't know the answer to that try to copy an existing file named say abc.txt to a*a, see what the error message will be. (Sorry to the rest of the group, obviously everyone knows the answers to that but it is not my fault we go there - and at the moment I don't feel like letting it go just because someone is too pushy with his nonsense). > Or do you mean that Don doesn't count as a "user" because he is using > filenames that you don't like? Or do you mean that you would be wrongly labelled mental just because you want to have the name written on your identity card to consist only of hieroglyphs and special characters. Don is a "user" as long as he uses the user interface. A programmer and a user are not the same thing in that contest and please do not go into more bollocks on obvious definitions like that. >>>> Of course he can hack his way into doing it, whether through some >>>> MS written hack which you say is not a hack or otherwise. >>> >>> The Win32 API allows files to be created or opened using "posix >>> semantics" for filenames, including case-sensitive files, characters >>> such as ":" and "*" in filenames, and multiple files differing only in >>> the case of their names. Even if you want to call the MS-supplied posix >>> compatibility layer a "hack", I don't think the standard Win32 API is a >>> hack. >> >> You may think whatever you want but using a low enough level call to >> create invalid directory entries is a hack, whoever may have written >> the code within the system call. >> Non-hack application code does not go that low in order to defeat the >> system-wide rules or compromise the system in other ways, there are >> always plenty of opportunities to kill a system. > > We are talking about the Win32 API "CreateFile" call here! This is how > you create files in Windows programming. If that is a "hack", then > /all/ windows programming is a "hack". While I don't know how this is done under windows I think you know that even less than I do. Your above means claim that every application written for windows has to prepare the name such that it will be a valid one. It is obvious that normal windows applications do not write their own name validations, if some call allows writing an invalid name then reading the OS manual will tell you that you must use another call prior to it which validates the name. You should demonstrate at least such basic programming knowledge if you want people to take your posts as something more than standard "always know better" babble by someone who does not really know what he is talking about. >> >>>> The problem remains and will remain, as unix does >>>> not output names but file identifiers (names consist of text, remember >>>> the alphabet and the character count). The fact that these identifiers >>>> have been misused as text for decades does not mean much beyond >>>> the expectations of hardcore unix users that the English alphabet >>>> will suddenly begin to have 52 characters. >>> >>> This goes back to your unique idea that files have a sort of colloquial >>> human-friendly nick-name that is a different concept from their >>> "filename" that everyone else uses. >> >> Blimey, so it is my unique idea that file names are meant also for human >> consumption/processing. > > No, it is your unique idea that an OS has to treat filenames using human > language rules because they are always for human processing and > consumption - Ah, now you are trying to cheat your way out of the hole. No, I never said that. I said that file names are ALSO for human consumption. Try to spell over the phone a file name like "ThIs Is An eXamPle Of A nAMe foR iDioTs". Then come and repeat your claim that file names - or whatever names which are represented in text - are to be compared case sensitive. Or simply stop posting nonsense. Dimiter
[toc] | [prev] | [next] | [standalone]
| From | Stefan Reuther <stefan.news@arcor.de> |
|---|---|
| Date | 2014-10-22 18:46 +0200 |
| Message-ID | <m28u1e.l0.1@stefan.msgid.phost.de> |
| In reply to | #18890 |
Dimiter_Popoff wrote: > On 22.10.2014 г. 16:21, David Brown wrote: >> On 22/10/14 14:19, Dimiter_Popoff wrote: >>> On 22.10.2014 г. 14:11, David Brown wrote: >>>>> 2. The user is not exposed to the bitstreams the OS stores but to to >>>>> text which consists of characters which are part of an alphabet, >>>>> for example the Latin alphabet as used in English has 26 characters. >>>> >>>> In other words, Windows mangles the names it is given. >>> >>> No. It reproduces the names exactly as the user has entered them. >> >> Don entered filenames, ... > > No, he wrote a program to squeeze these names through the system. > A user cannot enter names the system does not allow to be entered. No, he did not "squeeze these names through the system". He used a program written by Microsoft, for Windows, in the way it is meant to be used, and it obviously let him enter the names. NTFS can (and always could) be configured to be case-sensitive, which the SFU/Interix tools use through the POSIX subsystem. Of course, the Win32 subsystem which uses a different configuration isn't particularily happy about that, much in the same way the virtual DOS subsystem isn't particularily happy about names that don't fit into the 8.3 convention. Stefan
[toc] | [prev] | [next] | [standalone]
| From | Dimiter_Popoff <dp@tgi-sci.com> |
|---|---|
| Date | 2014-10-23 02:37 +0300 |
| Message-ID | <m29f3c$s9s$1@dont-email.me> |
| In reply to | #18895 |
On 22.10.2014 г. 19:46, Stefan Reuther wrote: > Dimiter_Popoff wrote: >> On 22.10.2014 г. 16:21, David Brown wrote: >>> On 22/10/14 14:19, Dimiter_Popoff wrote: >>>> On 22.10.2014 г. 14:11, David Brown wrote: >>>>>> 2. The user is not exposed to the bitstreams the OS stores but to to >>>>>> text which consists of characters which are part of an alphabet, >>>>>> for example the Latin alphabet as used in English has 26 characters. >>>>> >>>>> In other words, Windows mangles the names it is given. >>>> >>>> No. It reproduces the names exactly as the user has entered them. >>> >>> Don entered filenames, ... >> >> No, he wrote a program to squeeze these names through the system. >> A user cannot enter names the system does not allow to be entered. > > No, he did not "squeeze these names through the system". He used a > program written by Microsoft, for Windows, in the way it is meant to be > used, and it obviously let him enter the names. > > NTFS can (and always could) be configured to be case-sensitive, which > the SFU/Interix tools use through the POSIX subsystem. Of course, the > Win32 subsystem which uses a different configuration isn't particularily > happy about that, much in the same way the virtual DOS subsystem isn't > particularily happy about names that don't fit into the 8.3 convention. Apparently so. Though MS seem to be somewhat more than "particularly unhappy" about case sensitive name searches, I stumbled across their text in the link David looked up demonstrating his programmer's skills saying "do not assume case sensitivity", "can be used to but" etc., basically what I say about DPS - which is also perfectly capable of case dependent compares - and does these as well as the case independent ones likely faster than the rest, it compares 32 bit words - but I expect one would run into problems when going into not that chartered territory, just as Don did with MS. Dimiter
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2014-10-22 23:09 +0200 |
| Message-ID | <m296dl$uc$1@dont-email.me> |
| In reply to | #18890 |
On 22/10/14 16:26, Dimiter_Popoff wrote: > On 22.10.2014 г. 16:21, David Brown wrote: >> On 22/10/14 14:19, Dimiter_Popoff wrote: >>> On 22.10.2014 г. 14:11, David Brown wrote: >>> >>>> >>>>> 2. The user is not exposed to the bitstreams the OS stores but to to >>>>> text which consists of characters which are part of an alphabet, >>>>> for example the Latin alphabet as used in English has 26 characters. >>>> >>>> In other words, Windows mangles the names it is given. >>> >>> No. It reproduces the names exactly as the user has entered them. >>> >> >> Don entered filenames, ... > > No, he wrote a program to squeeze these names through the system. > A user cannot enter names the system does not allow to be entered. He typed "touch C*c". "touch" is an extremely common command on all posix systems, including the various versions of MS's "unix services for windows" throughout the history of Windows NT. So no, Don did not "write a program" or "hack the system" - he used a standard command line utility available to users. > >> Do you mean that because "a*b" has a non-letter, it is not a valid name? > > It might be, "*" is typically a reserved symbol for communication > between the user interface and the directory search code. > If the user interface won't let you do it chances are it is illegal. The point is that /some/ interfaces on Windows let you use this symbol (and other symbols, and filenames differing only in case), while other interfaces disallow entering such filenames, and mangle the view of such files. This is all using programs and utilities that come out of the box with Windows (at least the server and "ultimate" versions). > If you don't know the answer to that try to copy an existing file > named say abc.txt to a*a, see what the error message will be. > (Sorry to the rest of the group, obviously everyone knows the answers > to that but it is not my fault we go there - and at the moment I > don't feel like letting it go just because someone is too pushy > with his nonsense). > >> Or do you mean that Don doesn't count as a "user" because he is using >> filenames that you don't like? > > Or do you mean that you would be wrongly labelled mental just because > you want to have the name written on your identity card to consist > only of hieroglyphs and special characters. There are plenty of languages which are written in "hieroglyphs" or have special characters as part of their written form. I'm lucky - my name uses only characters from the 7-bit ASCII character set. But other people could certainly want their names written in non-ASCII characters. > > Don is a "user" as long as he uses the user interface. A programmer > and a user are not the same thing in that contest and please do not > go into more bollocks on obvious definitions like that. See above for a note on the "touch" user program. > >>>>> Of course he can hack his way into doing it, whether through some >>>>> MS written hack which you say is not a hack or otherwise. >>>> >>>> The Win32 API allows files to be created or opened using "posix >>>> semantics" for filenames, including case-sensitive files, characters >>>> such as ":" and "*" in filenames, and multiple files differing only in >>>> the case of their names. Even if you want to call the MS-supplied >>>> posix >>>> compatibility layer a "hack", I don't think the standard Win32 API is a >>>> hack. >>> >>> You may think whatever you want but using a low enough level call to >>> create invalid directory entries is a hack, whoever may have written >>> the code within the system call. >>> Non-hack application code does not go that low in order to defeat the >>> system-wide rules or compromise the system in other ways, there are >>> always plenty of opportunities to kill a system. >> >> We are talking about the Win32 API "CreateFile" call here! This is how >> you create files in Windows programming. If that is a "hack", then >> /all/ windows programming is a "hack". > > While I don't know how this is done under windows I think you know that > even less than I do. Your above means claim that every application > written for windows has to prepare the name such that it will be a > valid one. > It is obvious that normal windows applications do not write their own > name validations, if some call allows writing an invalid name then > reading the OS manual will tell you that you must use another call > prior to it which validates the name. Most programs would simply pass on the filename to the Win32 API (CreateFile, which by MS logic is also used to open existing files), and if the function returns an error about an invalid filename, that will be passed on to the user. Programs would normally only do their own validation if they had reason to be extra fussy. Note that the Win32 API supports two different semantics for file name validity, which you can choose - you can use "posix semantics", allowing case sensitive operation (and some extra characters), or "default windows semantics" with case insensitive operation. Either way, the function will check the validity of the operation requested. > You should demonstrate at least such basic programming knowledge > if you want people to take your posts as something more than standard > "always know better" babble by someone who does not really know what > he is talking about. Let me demonstrate my basic programming knowledge by my ability to look up CreateFile with google to find the MSDN page: <http://msdn.microsoft.com/en-us/library/windows/desktop/aa363858%28v=vs.85%29.aspx> Looking up the documentation for the "touch" program, to see that it is a common user program and not a "hack" or a special program written by Don, is left as an exercise to the reader. > >>> >>>>> The problem remains and will remain, as unix does >>>>> not output names but file identifiers (names consist of text, remember >>>>> the alphabet and the character count). The fact that these identifiers >>>>> have been misused as text for decades does not mean much beyond >>>>> the expectations of hardcore unix users that the English alphabet >>>>> will suddenly begin to have 52 characters. >>>> >>>> This goes back to your unique idea that files have a sort of colloquial >>>> human-friendly nick-name that is a different concept from their >>>> "filename" that everyone else uses. >>> >>> Blimey, so it is my unique idea that file names are meant also for human >>> consumption/processing. >> >> No, it is your unique idea that an OS has to treat filenames using human >> language rules because they are always for human processing and >> consumption - > > Ah, now you are trying to cheat your way out of the hole. No, I never > said that. I said that file names are ALSO for human consumption. And it has been pointed out that humans use wildly different rules for how they write according to their language, alphabet (or non-alphabetic writing system), and even their personal habits - thus the OS should not try to second-guess them. > > Try to spell over the phone a file name like "ThIs Is An eXamPle Of A > nAMe foR iDioTs". > Then come and repeat your claim that file names - or whatever names > which are represented in text - are to be compared case sensitive. Filenames that are meant to be typed by humans (or read over the phone) should be chosen to make sense - but most humans will do that automatically. And there is /no/ requirement to be case insensitive for that - /I/ certainly have no problem saying "readme dot txt, all small letters" or "readme dot txt, with a capital r". No case-insensitive system is going to protect someone from a file name like "This is an exampel of a name for idiots". Case-insensitivity made sense when there were computers with 6-bit characters. And it is at least consistent when you are limited to 8.3 capital letters purely from the 7-bit ASCII set. (And it can still make sense on small, niche OS'es where you need a simple and limited system.) But on a modern multi-lingual general-purpose OS and filesystem? At best you get an inordinately complex, inconsistent system that works for some languages and not others - that's Window's solution. > > Or simply stop posting nonsense. > > Dimiter >
[toc] | [prev] | [next] | [standalone]
| From | Dimiter_Popoff <dp@tgi-sci.com> |
|---|---|
| Date | 2014-10-23 03:06 +0300 |
| Message-ID | <m29gqh$pv$1@dont-email.me> |
| In reply to | #18904 |
On 23.10.2014 г. 00:09, David Brown wrote: > .... >> You should demonstrate at least such basic programming knowledge >> if you want people to take your posts as something more than standard >> "always know better" babble by someone who does not really know what >> he is talking about. > > Let me demonstrate my basic programming knowledge by my ability to look > up CreateFile with google to find the MSDN page: I suppose these skills will get you a secretary/typist job, at least you'll make it to the interview. > > <http://msdn.microsoft.com/en-us/library/windows/desktop/aa363858%28v=vs.85%29.aspx> Clicking once or twice on links in your discovery one sees how strongly MS discourage use of any case dependent search capabilities. Like I explained to you earlier text data can be compared either way given it is all preserved, how can you have a problem understanding *that*? >>>>>> The problem remains and will remain, as unix does >>>>>> not output names but file identifiers (names consist of text, >>>>>> remember >>>>>> the alphabet and the character count). The fact that these >>>>>> identifiers >>>>>> have been misused as text for decades does not mean much beyond >>>>>> the expectations of hardcore unix users that the English alphabet >>>>>> will suddenly begin to have 52 characters. >>>>> >>>>> This goes back to your unique idea that files have a sort of >>>>> colloquial >>>>> human-friendly nick-name that is a different concept from their >>>>> "filename" that everyone else uses. >>>> >>>> Blimey, so it is my unique idea that file names are meant also for >>>> human >>>> consumption/processing. >>> >>> No, it is your unique idea that an OS has to treat filenames using human >>> language rules because they are always for human processing and >>> consumption - >> >> Ah, now you are trying to cheat your way out of the hole. No, I never >> said that. I said that file names are ALSO for human consumption. > > And it has been pointed out that humans use wildly different rules for > how they write according to their language, .... So cheating did not work but why not persist by repeating yet again something completely irrelevant. >> Try to spell over the phone a file name like "ThIs Is An eXamPle Of A >> nAMe foR iDioTs". >> Then come and repeat your claim that file names - or whatever names >> which are represented in text - are to be compared case sensitive. > > Filenames that are meant to be typed by humans (or read over the phone) > should be chosen to make sense - but most humans will do that > automatically. So when creating a file name the system should know whether it will be spelt over the phone. Good, good, way to go, Einstein. Dimiter
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2014-10-23 10:18 +0200 |
| Message-ID | <m2adkt$453$1@dont-email.me> |
| In reply to | #18907 |
Dimiter, I have no idea why you are so obsessed with insulting me and posting pointless derogatory remarks. I have a pretty thick skin after many years of using Usenet, but I can't say I find it pleasant - especially from someone whose knowledge and experience I respect. We disagree on whether filenames should be case sensitive or case insensitive at the filesystem level. That should be fair enough - it's a technical disagreement, and there has been an exchange of ideas and thoughts in this area (by other people as well). But you have been dragging the disagreement down to a kindergarten squabble. I have tried to avoid retaliating, but I have failed - I have certainly been sarcastic and patronising, and thus encouraged you. In order to avoid getting completely out of hand, I will therefore have to stop posting in this thread, and will not reply to your points. I hope that next time we "meet" in this newsgroup, we will be back to the friendly and professional tone that is the standard in comp.arch.embedded. David
[toc] | [prev] | [next] | [standalone]
| From | Dimiter_Popoff <dp@tgi-sci.com> |
|---|---|
| Date | 2014-10-23 13:56 +0300 |
| Message-ID | <m2amsa$vku$1@dont-email.me> |
| In reply to | #18912 |
On 23.10.2014 г. 11:18, David Brown wrote: > Dimiter, I have no idea why you are so obsessed with insulting me and > posting pointless derogatory remarks. I have a pretty thick skin after > many years of using Usenet, but I can't say I find it pleasant - > especially from someone whose knowledge and experience I respect. > > We disagree on whether filenames should be case sensitive or case > insensitive at the filesystem level. That should be fair enough - it's > a technical disagreement, and there has been an exchange of ideas and > thoughts in this area (by other people as well). > > But you have been dragging the disagreement down to a kindergarten > squabble. I have tried to avoid retaliating, but I have failed - I have > certainly been sarcastic and patronising, and thus encouraged you. > > In order to avoid getting completely out of hand, I will therefore have > to stop posting in this thread, and will not reply to your points. I > hope that next time we "meet" in this newsgroup, we will be back to the > friendly and professional tone that is the standard in comp.arch.embedded. > > David > David, I am really a less patient person than I used to be say 5 years ago, the less time we have left the more we tend to care about it I suppose. I have had no problem when we disagree on something which can be argued either way; unfortunately the fact that file names are also for human consumption at the current evolution stage is no more arguable than the result of adding 1 to 1. You are clearly unable to accept you have been wrong on something that basic and ever since you first declared that file names were not for human but for machine processing you have been in track repeat flailing mode. While I know I am not patient at all (have never been), I don't think I was too impatient. I am glad you decided to put an end to it. Dimiter
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2014-10-23 15:59 +0200 |
| Message-ID | <m2b1jh$4qp$1@dont-email.me> |
| In reply to | #18916 |
On 23/10/14 12:56, Dimiter_Popoff wrote: > On 23.10.2014 г. 11:18, David Brown wrote: >> Dimiter, I have no idea why you are so obsessed with insulting me and >> posting pointless derogatory remarks. I have a pretty thick skin after >> many years of using Usenet, but I can't say I find it pleasant - >> especially from someone whose knowledge and experience I respect. >> >> We disagree on whether filenames should be case sensitive or case >> insensitive at the filesystem level. That should be fair enough - it's >> a technical disagreement, and there has been an exchange of ideas and >> thoughts in this area (by other people as well). >> >> But you have been dragging the disagreement down to a kindergarten >> squabble. I have tried to avoid retaliating, but I have failed - I have >> certainly been sarcastic and patronising, and thus encouraged you. >> >> In order to avoid getting completely out of hand, I will therefore have >> to stop posting in this thread, and will not reply to your points. I >> hope that next time we "meet" in this newsgroup, we will be back to the >> friendly and professional tone that is the standard in >> comp.arch.embedded. >> >> David >> > > David, > I am really a less patient person than I used to be say 5 years ago, > the less time we have left the more we tend to care about it I > suppose. > > I have had no problem when we disagree on something which can > be argued either way; unfortunately the fact that file names are > also for human consumption at the current evolution stage is > no more arguable than the result of adding 1 to 1. > You are clearly unable to accept you have been wrong on > something that basic and ever since you first declared that > file names were not for human but for machine processing you > have been in track repeat flailing mode. > While I know I am not patient at all (have never been), I don't > think I was too impatient. > I am glad you decided to put an end to it. > > Dimiter > I suspect that somewhere near the beginning, we have got something mixed up and misunderstood. I can't say for sure what it is, and I don't want to try and dig it up - but I think the result is that we have been arguing slightly at cross-purposes. Thus perhaps you have argued that 1 + 1 = 2, while I have argued that 2 + 2 = 4, and that is why neither of us will back down! (Let us not try to find what went wrong, and certainly not attempt to find out whose fault it might be, as we would argue about that too.) I just hope that Don learned whatever he needed to know from this thread :-) David.
[toc] | [prev] | [standalone]
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
Back to top | Article view | comp.arch.embedded
csiph-web