EmbeddedRelated.com
Forums
The 2026 Embedded Online Conference

Filesystem syntax constraints under Windows

Started by Don Y October 10, 2014
Dimiter_Popoff wrote:
> On 13.10.2014 г. 20:26, Stefan Reuther wrote: >>>> Dimiter_Popoff wrote: >>>>> It has worked for a few milennia, whether you like it or not. Just >>>>> because a few programmers do not want to be bothered (or are incapable >>>>> of) handling the naming conventions we have is no good reason to ask >>>>> for a change. >>>> >>>> In previous millenia, people did not try to build systems that work >>>> internationally. >>> >>> Yeah. And because they do now all the whining unix followers would >>> have the millennia old grammar reinvented just to suit the fact they >>> have been led by their leader into the wrong corner. >>> The fact is they got what they deserved (as does anybody following >>> any leader). Tons of defunct software because of a fundamentally >>> broken filesystem. >> >> Last time I looked, Unix software worked fine. > > Not really, the relevant part has never worked and still does not work. > See my example in a previous post how may versions of say > "index.htm" Index.htm INDEX.HTM you need.
I see a file "index.htm", I open a file "index.htm". Works fine for me.
>> As we have learned, defining semantics for "just ignore case" is hard >> (if you're in Russia, what reason do you have to prefer the I<>i case >> pair over the I<>&#305; case pair?). > > > How you treat cases when you record a string (be it a filename or not) > is up to the application writing the name - or just the user typing it > in. Once it is recorded along with the case information you no longer need > to know in which language it is or which alphabet this is, for that. > Just the character set - which may cover a lot of alphabets and their > variations (check upthread my way of doing it in dps, I explained it).
I have shown you examples why this cannot work without information about the locale (the "i<>I" case, which caused real trouble in PHP). Of course you can record a language along with the file name. Or you can store the file name in a normalized format. Or implement some fuzziness, like "if they ask for INDEX.HTML, I'll give them index.html if there is no &#305;ndex.html". But why? Think of all the software breakage you could cause by creating an &#305;ndex.html! (Much like the software breakage you can cause by making a c:\program.exe.)
> Filenames which are for human processing consist of characters, not of > bytes.
IBTD. File names are for processing by programs. It is true that many file names are processed by programs on behalf of humans, but I wouldn't even claim the majority of files are created directly on behalf of a user (when every web page access generates a dozen temporary files). But it's the responsibility of the program to deal with case conversions. And, actually, programs do that just fine. When I type a file name, typical GUI file requesters immediately offer possible completions, or move the cursor in the file list; of course they handle case differences here.
> What I see is that you do not want to accept obvious facts, like > what is a byte and what is a character, what is a character > string and what is a sentence with meaning.(I assume you do know these?)
Of course I know what the difference between a byte and a character is. The simplest summary: byte = kernel thing, character = user thing (because the user can configure the mapping between bytes and characters. LC_CTYPE in unix, 'chcp' in Windows). A file system is a kernel thing. Stefan
On 14.10.2014 &#1075;. 19:59, Stefan Reuther wrote:
>> ... >> Not really, the relevant part has never worked and still does not work. >> See my example in a previous post how may versions of say >> "index.htm" Index.htm INDEX.HTM you need. > > I see a file "index.htm", I open a file "index.htm". Works fine for me.
Yeah. What an unmatched wisdom, why would I expect anything less than that from a devotee.
>> Filenames which are for human processing consist of characters, not of >> bytes. > > IBTD. File names are for processing by programs.
Are you sure you do work related to comp.arch.embedded? So far you are only posting religious babble like the above. Beg to differ all you want, be welcome to call it "my strong opinion" when I say that 1+1=2, feel free to disagree and write another ton of nonsense.
>> What I see is that you do not want to accept obvious facts, like >> what is a byte and what is a character, what is a character >> string and what is a sentence with meaning.(I assume you do know these?) > > Of course I know what the difference between a byte and a character is. > The simplest summary: byte = kernel thing, character = user thing > (because the user can configure the mapping between bytes and > characters. LC_CTYPE in unix, 'chcp' in Windows). A file system is a > kernel thing.
So in reality you don't know. Neither did you grasp the obvious fact that the unix problem is because of the filesystem <-> user INTERFACE, a problem which survives for decades and which devotees like yourself want to fix by persuading the world to being to read/write bitstreams rather than text, like here: > I see a file "index.htm", I open a file "index.htm". Works fine > for me. I really have no more time for such nonsense, if I had I would not be reading comp.arch.embedded but some facebook group or some forum for techy housewives. Dimiter
On 14/10/14 20:39, Dimiter_Popoff wrote:

> I really have no more time for such nonsense, if I had I would not > be reading comp.arch.embedded but some facebook group or some forum > for techy housewives. >
Dimiter, I really don't know what your problem is here, but I see no reason for this stream of insults directed at people giving clear, rational and technical counterpoints to your opinion here. Usually such ad hominem attacks are used by a person who realises that they have lost the rational argument, and are trying to "win" by the written equivalent of sticking their fingers in their ears and shouting "la, la, la". Perhaps your aim was to irritate people and make it clear that you are so smart and so experienced (more so than any other OS designers, such as those behind Unix), that you don't need to listen to anybody or consider any other viewpoint. If that is the case, then congratulations - and I'm sure you will be rewarded with a lot fewer helpful or interesting replies in the future. But perhaps it's just that I have a religious dislike of insults and misogynist language.
On 15.10.2014 &#1075;. 00:29, David Brown wrote:
> On 14/10/14 20:39, Dimiter_Popoff wrote: > >> I really have no more time for such nonsense, if I had I would not >> be reading comp.arch.embedded but some facebook group or some forum >> for techy housewives. >> > > Dimiter, I really don't know what your problem is here, but I see no > reason for this stream of insults directed at people giving clear, > rational and technical counterpoints to your opinion here. Usually such > ad hominem attacks are used by a person who realises that they have lost > the rational argument, and are trying to "win" by the written equivalent > of sticking their fingers in their ears and shouting "la, la, la".
Yes, this is what you and Stefan have been doing for a few posts now. Repeating nonsense and hoping that nobody will understand you are talking nonsense. In comp.hobby.wannabe, may be. But not here. Everyone can read the thread, remember. You may want to stop digging, meanwhile I am sure you have realized you are in yet another hole. You were hasty to give an opinion on something you are ignorant about and now you madly try to prove you were right, talk of your "arguments" that 1+1 is not 2 - do you seriously hope anyone will buy your "arguments"? Try some other group for that. Dimiter
On 14/10/14 23:46, Dimiter_Popoff wrote:
> On 15.10.2014 &#1075;. 00:29, David Brown wrote: >> On 14/10/14 20:39, Dimiter_Popoff wrote: >> >>> I really have no more time for such nonsense, if I had I would not >>> be reading comp.arch.embedded but some facebook group or some forum >>> for techy housewives. >>> >> >> Dimiter, I really don't know what your problem is here, but I see no >> reason for this stream of insults directed at people giving clear, >> rational and technical counterpoints to your opinion here. Usually such >> ad hominem attacks are used by a person who realises that they have lost >> the rational argument, and are trying to "win" by the written equivalent >> of sticking their fingers in their ears and shouting "la, la, la". > > Yes, this is what you and Stefan have been doing for a few posts now. > Repeating nonsense and hoping that nobody will understand you are > talking nonsense. > In comp.hobby.wannabe, may be. But not here. Everyone can read > the thread, remember. You may want to stop digging, meanwhile > I am sure you have realized you are in yet another hole. >
You might want to remember that yourself. Everyone can read that how the discussion played out. And even if everyone agreed with you that OS'es and filesystems should be case insensitive, I think that your posting style will make a far more lasting impression than any technical issues. But that is for others to decide - not you or me.
> You were hasty to give an opinion on something you are ignorant > about and now you madly try to prove you were right, talk of your > "arguments" that 1+1 is not 2 - do you seriously hope anyone > will buy your "arguments"? > > Try some other group for that. > > Dimiter > >
Am 14.10.2014 um 12:28 schrieb Dimiter_Popoff:

> Sorry David, I don't do religion.
I have to call BS on that. The way you've reacted to people voicing any different opinion on this issue is a textbook-grade example case of exactly what happens when people have their religious dogmas challenged. So: not only do you do religion quite heavily. This issue evidently _is_ your religion.
On Mon, 13 Oct 2014 20:18:34 +0200, David Brown wrote:

> On 13/10/14 19:14, Stefan Reuther wrote: >> David Brown wrote: >>> On 12/10/14 12:07, Stefan Reuther wrote: >>>> David Brown wrote: >>>>> To my knowledge, the only successful use of alternate data streams >>>>> in an NTFS file was a way to hide viruses without changing the >>>>> apparent size of a file. >>>> >>>> They are also used to store extended attributes such as a marker >>>> "this .exe file was downloaded from the internet, display a scary >>>> message when the user tries to run it". >>> >>> That's interesting to know. (That particular message is more >>> irritating than scary - /of course/ I want to run the file, that's why >>> I downloaded it in the first place!) >> >> Because you know what an exe file is and why you'd want to download >> one. >> Now think of the grandma who got an email that says she should pay that >> invoice she'll find in invoice10298234.doc.zip.exe, and if she doesn't, >> someone will come, kill her dog, poison her geraniums, slash her tires >> and spray-paint her door :-) >> >> > That's why my mother has a Mac, and my mother-in-law has Linux mint :-)
Yes. ISTR it was MacOS where those extra file "forks" (were they called? ) were first made popular. Where Windows maps from the file extension, and Posix applies magic to a few bytes from the beginning of the file, MacOS identified the relevant processing application within a non-data area in the file. Mel.
On 15/10/14 20:43, Mel Wilson wrote:
> On Mon, 13 Oct 2014 20:18:34 +0200, David Brown wrote: > >> On 13/10/14 19:14, Stefan Reuther wrote: >>> David Brown wrote: >>>> On 12/10/14 12:07, Stefan Reuther wrote: >>>>> David Brown wrote: >>>>>> To my knowledge, the only successful use of alternate data streams >>>>>> in an NTFS file was a way to hide viruses without changing the >>>>>> apparent size of a file. >>>>> >>>>> They are also used to store extended attributes such as a marker >>>>> "this .exe file was downloaded from the internet, display a scary >>>>> message when the user tries to run it". >>>> >>>> That's interesting to know. (That particular message is more >>>> irritating than scary - /of course/ I want to run the file, that's why >>>> I downloaded it in the first place!) >>> >>> Because you know what an exe file is and why you'd want to download >>> one. >>> Now think of the grandma who got an email that says she should pay that >>> invoice she'll find in invoice10298234.doc.zip.exe, and if she doesn't, >>> someone will come, kill her dog, poison her geraniums, slash her tires >>> and spray-paint her door :-) >>> >>> >> That's why my mother has a Mac, and my mother-in-law has Linux mint :-) > > Yes. ISTR it was MacOS where those extra file "forks" (were they called? > ) were first made popular. Where Windows maps from the file extension, > and Posix applies magic to a few bytes from the beginning of the file, > MacOS identified the relevant processing application within a non-data > area in the file. > > Mel. >
I don't know what they are called on the Mac, nor who "invented" them, but "extended attributes" of one sort or another are supported by many OS's and filesystems. I haven't used them directly or knowingly, but I suppose they are used behind the scenes in different systems and desktops for things like image thumbnails, "emblems", or filetype information.
On 15.10.2014 &#1075;. 20:57, Hans-Bernhard Br&ouml;ker wrote:
> Am 14.10.2014 um 12:28 schrieb Dimiter_Popoff: > >> Sorry David, I don't do religion. > > I have to call BS on that. The way you've reacted to people voicing any > different opinion on this issue is a textbook-grade example case of > exactly what happens when people have their religious dogmas challenged. > > So: not only do you do religion quite heavily. This issue evidently > _is_ your religion.
Whatever you say. Call again when you can point us to an example where I was wrong or doing dogma. I understand you badly want it to be this way, unfortunately for you it is not - and you know it.
On Wed, 15 Oct 2014 18:43:22 +0000 (UTC), Mel Wilson
<mwilson@the-wire.com> wrote:


>ISTR it was MacOS where those extra file "forks" (were they called? >) were first made popular. Where Windows maps from the file extension, >and Posix applies magic to a few bytes from the beginning of the file, >MacOS identified the relevant processing application within a non-data >area in the file.
Yes. Macintosh executables had forks: every file contained a "data" fork, executables contained an additional "resource" fork where their code lived. Window/widget templates, images, icons, sound files, etc. all went into the data fork of the executable. It was backward to the traditional notion of "resources" as things for code to use, but at a developer conference I attended it was explained that "executables have the resources to use data". It also made some sense to think of code as a resource in light of the Macintosh's small memory (relatively, for a desktop) and it's memory/resource manager that allowed demand loading/unloading of code. George
The 2026 Embedded Online Conference