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

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

Filesystem syntax constraints under Windows

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

Contents

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

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

#18628

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<>ı 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 ındex.html". But why? Think of all the software breakage you could
cause by creating an ı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

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

#18631

On 14.10.2014 г. 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

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

#18633

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.

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

#18636

On 15.10.2014 г. 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

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

#18637

On 14/10/14 23:46, Dimiter_Popoff wrote:
> On 15.10.2014 г. 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
>
>

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

#18508

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

In theory (I haven't tried this), you can create multiple files in an
NTFS directory that differ only by case, because it is required for
posix compatibility.  But even on *nix systems, where this works
perfectly well, it is not recommended practice because it can easily
confuse people.

> 
>> Don, why are you asking about this?  Are you trying to implement a
>> non-native filesystem and want to support as much as Windows allows?  If
>> so, then the answer might depend on how that filesystem interacts with
>> Windows.  (I am not sure that I can give you more information no matter
>> what you answer - but it might be of some help.)
> 
> I don't have a filesystem.  Rather, the typical filesystem concept
> is used to manage a universe of (possibly parallel) nested namespaces.
> Each object defines the rules for the namespace(s) that it exports.
> I.e., the valid syntax for identifying portions *of* that object.
> 
> So, a "directory/folder" (to use a familiar concept) might support
> objects named:
> - ReadMe.txt
> - README.TXT
> - Read/\/\e
> - Garage:Door:Actuator
> - OutsideTemperature
> 
> The Garage:Door:Opener object might support objects (methods) named "open"
> and "close" and "current_state".
> 
> I want to be able to make any of these named objects accessible under
> various other environments.  If the host OS('s) enforce their own
> concept of "what constitutes a name", then I either have to adopt names
> FOR EXPORTED OBJECTS that are compatible with those OS('s) -- i.e.,
> some GCD thereof -- or provide a translation interface (create a
> parallel namespace for exported objects such that the exported names
> comply with the rules of the host OS).
> 
> OTOH, if name parsing is left to the filesystem implementation (i.e.,
> as it is in my implementation), then all I have to do is port my
> implementation to each of those host OS's.
> 
>> Even if it is possible to redefine things like directory separators, it
>> might cause a lot more confusion and therefore not be worth implementing
>> (just like using files whose names differ only by letter case).
> 
> I'm not keen on letting the tail wag the dog.  If Windows has a limitation,
> that's Windows' problem.  I'd be comfortable having Windows users bear the
> inconvenience of Windows' limitations (just like I wouldn't restrict myself
> to 8.3 names just to make life easy for DOS users).
> 
>> Also consider path lengths in this - the path length limitations are
>> different within Windows itself and in NTFS.
> 
> Yes.  But I think much of that issue inherently "goes away" when addressed
> as an exported namespace.  I.e., ONLY what the (Windows) user needs to see
> has to be made available to him/her.  And, at some convenient "mount point"
> (I guess that's still "drive letter" in the MS world).
> 
> So, the exported namespace can represent:
>     some/very/long/traditional/pathname/to/a/file as "file"
>     some/other/file as "file2"
>     some.particular\method as "verb"
>     That(&*^@$%(Fool as "A_Fine_Gentleman"
> 
> [note I've tried to show how to accommodate the host's naming rules as
> well]

If I understand you correctly (I'm not sure I do fully - but that's okay
for now), then I suspect your best idea is to restrict your names to
plain English alphabet letters, assuming case-preservation but not
case-sensitivity, with a few specific punctuation symbols.  Treat "/" as
a directory separator - it should work fine on almost any reasonable
system.

Punctuation that usually works without trouble is ".", "_", "-" and "+".
 Most other symbols will work in some circumstances, but can cause
issues in particular cases (such as needed escapes or inverted commas
when used from the command line).

So if you want a namespace separator, without causing directory changes
or other complications, pick one of "._-+".

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

#18514

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

>>> I believe you can store case-sensitive named files on NTFS as well -
>>> it's part of the posix compliance of the filesystem (harking back to the
>>> days when MS were still pretending to cooperate with other OS's).
>>
>> Preserving (and even *enforcing*) case doesn't guarantee that
>> identifiers differing *solely* in case can coexist in the same
>> container!  E.g., ReadMe, READme, ReAdMe, etc.
>
> In theory (I haven't tried this), you can create multiple files in an
> NTFS directory that differ only by case, because it is required for
> posix compatibility.  But even on *nix systems, where this works
> perfectly well, it is not recommended practice because it can easily
> confuse people.

The user interface to the (NTFS) filesystem doesn't provide a mechanism
for doing so.  E.g., creating "ReadMe" when "README" already exists doesn't
add another file (it simply overwrites the first one -- I think preserving
the original name, as well -- NOT the "new" filename!)

I will have to try it in an exported portion of an NTFS filesystem
accessed via NFS.  Or, an NTFS filesystem under some other OS...

>>> Don, why are you asking about this?  Are you trying to implement a
>>> non-native filesystem and want to support as much as Windows allows?  If
>>> so, then the answer might depend on how that filesystem interacts with
>>> Windows.  (I am not sure that I can give you more information no matter
>>> what you answer - but it might be of some help.)
>>
>> I don't have a filesystem.  Rather, the typical filesystem concept
>> is used to manage a universe of (possibly parallel) nested namespaces.
>> Each object defines the rules for the namespace(s) that it exports.
>> I.e., the valid syntax for identifying portions *of* that object.
>>
>> So, a "directory/folder" (to use a familiar concept) might support
>> objects named:
>> - ReadMe.txt
>> - README.TXT
>> - Read/\/\e
>> - Garage:Door:Actuator
>> - OutsideTemperature
>>
>> The Garage:Door:Opener object might support objects (methods) named "open"
>> and "close" and "current_state".
>>
>> I want to be able to make any of these named objects accessible under
>> various other environments.  If the host OS('s) enforce their own
>> concept of "what constitutes a name", then I either have to adopt names
>> FOR EXPORTED OBJECTS that are compatible with those OS('s) -- i.e.,
>> some GCD thereof -- or provide a translation interface (create a
>> parallel namespace for exported objects such that the exported names
>> comply with the rules of the host OS).
>>
>> OTOH, if name parsing is left to the filesystem implementation (i.e.,
>> as it is in my implementation), then all I have to do is port my
>> implementation to each of those host OS's.
>>
>>> Even if it is possible to redefine things like directory separators, it
>>> might cause a lot more confusion and therefore not be worth implementing
>>> (just like using files whose names differ only by letter case).
>>
>> I'm not keen on letting the tail wag the dog.  If Windows has a limitation,
>> that's Windows' problem.  I'd be comfortable having Windows users bear the
>> inconvenience of Windows' limitations (just like I wouldn't restrict myself
>> to 8.3 names just to make life easy for DOS users).
>>
>>> Also consider path lengths in this - the path length limitations are
>>> different within Windows itself and in NTFS.
>>
>> Yes.  But I think much of that issue inherently "goes away" when addressed
>> as an exported namespace.  I.e., ONLY what the (Windows) user needs to see
>> has to be made available to him/her.  And, at some convenient "mount point"
>> (I guess that's still "drive letter" in the MS world).
>>
>> So, the exported namespace can represent:
>>      some/very/long/traditional/pathname/to/a/file as "file"
>>      some/other/file as "file2"
>>      some.particular\method as "verb"
>>      That(&*^@$%(Fool as "A_Fine_Gentleman"
>>
>> [note I've tried to show how to accommodate the host's naming rules as
>> well]
>
> If I understand you correctly (I'm not sure I do fully - but that's okay
> for now), then I suspect your best idea is to restrict your names to
> plain English alphabet letters, assuming case-preservation but not
> case-sensitivity, with a few specific punctuation symbols.  Treat "/" as
> a directory separator - it should work fine on almost any reasonable
> system.

That's the tail wagging dog approach.  What I am trying to understand is
how Windows (and other OS's) parse pathnames -- where that functionality
resides.  I.e., is it filesystem specific or embedded in the OS's notion
of "what comprises a pathname".

E.g., Windows recognizes // prefix for network shares.  You can conceivably
argue that "ftp://" is just another part of the notion of a filesystem.

(In my case, I can create an object named "ftp://" at some particular point
in some particular namespace -- e.g., /my/personal/directory/ftp:// -- and
bind an "FTP resolver" to that "ftp://" object.  Then, when any application
walks that path, entering the "ftp://" object causes *it* to parse the
balance of the pathname:   /my/personal/directory/ftp://google.com/foobar)

I.e., parsing a pathname is expensive, for me -- because each "level"
requires invoking a "walk" method on a different object.  But, it isn't
done often -- if you want to make walks quicker, create a second namespace
and bind the final entities (foobar in the above example) to nice short
names at the TOP of that namespace!  The new namespace acts like a cache
of sorts.

*If* Windows passes the pathname for a given mount point to the "handler"
for that mounted filesystem and lets that handler resolve it, then I
should be free to map any characters into any functionality I want.

So, I can have:
     traffic/10.0.1.23/inbound
     traffic/fe80::1%lo0/outbound
etc. WITHOUT having to create some artificial naming scheme that maps
the "ideal" names into something that "Windows" can handle:
     traffic/fe80__1&lo0

The whole point is to let each "object" define the rules for the names
of its components (or objects beneath it) in a manner that makes sense
in the context of the object.

E.g., if you treat "http://" as a top level object (an HTTP resolver),
then *it* applies whatever rules it deems appropriate to the objects
beneath it -- "host names".  I.e., <hostname> is case insensitive.

A <hostname> object, in turn, defines the rules for objects beneath
it -- "host directories".  I.e., <hostdir> is case SENSITIVE.

In the "traffic" example, the next level happens to allow names to be
bound to (things that look like) "IP addresses".  So, the syntax allows
characters that you wouldn't encounter in Windows, etc.

> Punctuation that usually works without trouble is ".", "_", "-" and "+".
> Most other symbols will work in some circumstances, but can cause
> issues in particular cases (such as needed escapes or inverted commas
> when used from the command line).

> So if you want a namespace separator, without causing directory changes
> or other complications, pick one of "._-+".

I don't have a universal notion of a "separator".  E.g., the above example
could just as easily have been:
     traffic10.0.1.23inbound
     trafficfe80::1%lo0outbound

[This can make for some interesting dilemmas if not used carefully!  :>
But, I think it worth the cost to not reserve a delimiter at each level
in the hierarchy.  So, you can have "foo" as a file coexisting alongside
"foo" as a folder -- in windows (i.e., the type of object effectively
adds another dimension to the identifier)]

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

#18504

On 10/10/2014 2:06 AM, glen herrmannsfeldt wrote:
> Don Y <this@is.not.me.com> wrote:
>
>> Does anyone know which filesystem naming constraints are imposed
>> in Windows itself vs. the file system layer?  Said another way,
>> which constraints are *invariants* regardless of the filesystem?
>
>> E.g., can a non-native filesystem redefine '+' to replace "../"?
>> Or, allow support for ':' in names?  Or, replace '\' with '/'?
>> Or, ...
>
> Interesting question.
>
> It is well known that the actual system calls accept either / or \
> as a separator.  The command option processor uses / for options,
> and so requires \ for the separator.

The problem is, these are just observations from *outside* the system.
You (I) don't know if the "system" imposes these conventions... OR, if
it relies on the filesystem implementation to impose conventions that
are appropriate for that specific file system!

E.g., imagine the "system" invokes a file system specific *method*
to "parse pathname".  In that case, all the system does is parse
enough of a pathname to get to a particular mount point, *notice*
which sort of file system is mounted *at* that mount point, then
pass the balance of the pathname off to filesystem->parse_pathname().

Ancient versions of MS C had library routines to parse pathnames
that hard-coded such separators.  But, that still doesn't indicate if
this was mimicking a service performed within the filesystems of
that era *or* was the sole mechanism for handling pathnames.

> The more interesting cases come when you use NFS.

That's an idea!  I have NFS client and server running under Windows.
I can mount an external filesystem and see if the Windows client
recognizes "FILENAME" and "filename" as two coexisting files.  And,
if it "does the right thing" when I refer to one or the other.

Similarly, export a portion of the Windows filesystem ("Foo") and verify
that it can ONLY be accessed as "Foo" (and not "fOo" or "FOO").

> I was just reading yesterday that it is possible to have an NFS
> server on a Windows system that allows for case significant names.
> (Unlike most that are case preserving.)
>
> The NFS protocols are independent of the actual separator.
>
> The : in drive selection has to be processed pretty early.
> I am not so sure what to say about : later in the name.

Again, it depends on whether the *system* implements this as a
"rule".  You can think of drive letters as objects at the "root"
of the filesystem.  Rules for objects at that level may require
<letter>':' (among other top level name conventions).

Or, it could be a hardwired prohibition elsewhere in the filesystem
hierarchy.

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

That's only an issue if *it* hardcodes an algorithm for extracting
current directory (instead of calling a filesystem specific *method*
for doing so).

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

#18511

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

Here is what Microsoft has to say on the topic:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247%28v=vs.85%29.aspx

TL;DR, the reserved characters are
- "\", "/" for the path separator
- ":" for the drive letter separator, and to separate file names
  and alternate data streams
- "?" and "*" because they are used in wildcards
- ">", "<", "|", and """ because they are used in shell syntax

The 'CreateFile' function refuses to create files with these names. It
might be possible to use some lower-level interface to create such
files, but that wouldn't get you much as no other program would be able
to access them.

Thus, for the specific questions: a file system driver could interpret
"+" to mean the parent directory. It can also somehow support ":" within
file names (at least NTFS manages to do that somehow for alternate data
streams). Replacing "\" with "/" is automatic in some sense, because the
system already supports both as the directory separator.


  Stefan

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

#18519

Stefan Reuther <stefan.news@arcor.de> wrote:
> Don Y wrote:
>> Does anyone know which filesystem naming constraints are imposed
>> in Windows itself vs. the file system layer?  Said another way,
>> which constraints are *invariants* regardless of the filesystem?
 
(snip)

> Here is what Microsoft has to say on the topic:
> http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247%28v=vs.85%29.aspx

> TL;DR, the reserved characters are
> - "\", "/" for the path separator
> - ":" for the drive letter separator, and to separate file names
>  and alternate data streams
> - "?" and "*" because they are used in wildcards
> - ">", "<", "|", and """ because they are used in shell syntax

(snip)

I haven't actually done this for a while, but I believe that NFS 
processes path components separately, such that it is independent
of the separator character. Forgetting exactly how NFS worked,
I tried a google search for:

nfs allowed characters

the first hit is in microsoft.com:

http://support2.microsoft.com/kb/324218

which described character translation for Windows based NFS servers.

As far as I know, the only character that you can't have in a path
component is /, being the separator. 

There are also NFS implementations for VMS, which has a different
way to do paths and path separation.  I believe VMS has other
restricted characters, though.

-- glen

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

#18525

On 10/10/2014 9:42 AM, Stefan Reuther wrote:
> Don Y wrote:
>> Does anyone know which filesystem naming constraints are imposed
>> in Windows itself vs. the file system layer?  Said another way,
>> which constraints are *invariants* regardless of the filesystem?
>>
>> E.g., can a non-native filesystem redefine '+' to replace "../"?
>> Or, allow support for ':' in names?  Or, replace '\' with '/'?
>> Or, ...
>
> Here is what Microsoft has to say on the topic:
> http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247%28v=vs.85%29.aspx
>
> TL;DR, the reserved characters are
> - "\", "/" for the path separator
> - ":" for the drive letter separator, and to separate file names
>    and alternate data streams
> - "?" and "*" because they are used in wildcards
> - ">", "<", "|", and """ because they are used in shell syntax
>
> The 'CreateFile' function refuses to create files with these names. It
> might be possible to use some lower-level interface to create such
> files, but that wouldn't get you much as no other program would be able
> to access them.

This suggests I just come up with some klunky OBVIOUS algorithm to translate
my names to names compatible with Windows.  And, push the problem of sorting
that mess out onto the Windows user -- in much the same way that the 8.3
user has to guess at the shortened forms of LFN's.

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

#18531

On Fri, 10 Oct 2014 13:43:31 -0700, Don Y <this@is.not.me.com> wrote:

>On 10/10/2014 9:42 AM, Stefan Reuther wrote:
>> Don Y wrote:
>>> Does anyone know which filesystem naming constraints are imposed
>>> in Windows itself vs. the file system layer?  Said another way,
>>> which constraints are *invariants* regardless of the filesystem?
>>>
>>> E.g., can a non-native filesystem redefine '+' to replace "../"?
>>> Or, allow support for ':' in names?  Or, replace '\' with '/'?
>>> Or, ...
>>
>> Here is what Microsoft has to say on the topic:
>> http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247%28v=vs.85%29.aspx
>>
>> TL;DR, the reserved characters are
>> - "\", "/" for the path separator
>> - ":" for the drive letter separator, and to separate file names
>>    and alternate data streams

I had completely forgotten the NTFS alternate data streams, since at
least in early NT versions, there were several issues using these
alternate streams.

There are similar issues with file systems supporting multiple
versions of a file, such as VMS with multiple versions with same name
but different versions in the same directory. Version control software
also save multiple versions of a file. These can be problematic, when
trying to map these to a foreign system.
 
>> - "?" and "*" because they are used in wildcards
>> - ">", "<", "|", and """ because they are used in shell syntax
>>
>> The 'CreateFile' function refuses to create files with these names. It
>> might be possible to use some lower-level interface to create such
>> files, but that wouldn't get you much as no other program would be able
>> to access them.
>
>This suggests I just come up with some klunky OBVIOUS algorithm to translate
>my names to names compatible with Windows.  And, push the problem of sorting
>that mess out onto the Windows user -- in much the same way that the 8.3
>user has to guess at the shortened forms of LFN's.

Sorting file names for human consumption is a very culture specific
issue, even with ISO/IEC 8859-x  not to mention Unicode. The sorting
for display needs to be done at the user machine at the language
selected by the currently logged in user preference. For internal data
processing, strict binary sorting order could be used, but for user
interaction, the cultural aspect should be noted.

One aspect that I haven't seen discussed in this thread is that a
"file" does not necessary have a single "name". While there may be
physical allocations of blocks on a disk and there might be some kind
of index file entry for those, there can be multiple directory entries
with different file or multiple entries in multiple directories
pointing to the same physical file. Various links and directory
entries are used  e.g. for user, protection or language specific views
to create multiple views of a file.
 

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

#18532

On 10/11/2014 1:06 AM, upsidedown@downunder.com wrote:
> On Fri, 10 Oct 2014 13:43:31 -0700, Don Y <this@is.not.me.com> wrote:

>>> The 'CreateFile' function refuses to create files with these names. It
>>> might be possible to use some lower-level interface to create such
>>> files, but that wouldn't get you much as no other program would be able
>>> to access them.
>>
>> This suggests I just come up with some klunky OBVIOUS algorithm to translate
>> my names to names compatible with Windows.  And, push the problem of sorting
>> that mess out onto the Windows user -- in much the same way that the 8.3
>> user has to guess at the shortened forms of LFN's.
>
> Sorting file names for human consumption is a very culture specific
> issue, even with ISO/IEC 8859-x  not to mention Unicode. The sorting
> for display needs to be done at the user machine at the language
> selected by the currently logged in user preference. For internal data
> processing, strict binary sorting order could be used, but for user
> interaction, the cultural aspect should be noted.
>
> One aspect that I haven't seen discussed in this thread is that a
> "file" does not necessary have a single "name". While there may be
> physical allocations of blocks on a disk and there might be some kind
> of index file entry for those, there can be multiple directory entries
> with different file or multiple entries in multiple directories
> pointing to the same physical file. Various links and directory
> entries are used  e.g. for user, protection or language specific views
> to create multiple views of a file.

Recall that I am only using the concept of "files" to relate this to
a conventional OS mechanism.  In my case, each *name* (in a namespace)
is backed by a particular server.  Names that would be the equivalent
of "files" (persistent data on some sort of medium) would be backed by a
"file server".

But, other names may be bound to things like dynamic kernel or process
structures, system variables, hardware devices, etc.  E.g., "time_of_day"
may provide the current time of day (in some particular format) when read.
"GarageDoor" may cause the garage door to open when the string "open" is
written to it; close when "close" is supplied.

The names in a namespace can be bound to a variety of different types of
objects.  As well as multiple instances of the *same* object.  E.g.,
"time of day" and "now" can both be bound to the same object.  Or, to
different accessors on a single object.

I think this is the solution to my problem:  I can freely create ANOTHER
namespace that I populate with "Windows compatible names" and export
*this* to the Windows host.  So, I could bind the name "ReadMe" in the
exported namespace to the same object that the local system has named
"Read/\/\e" (which would upset Windows' notion of a "proper" name to
reside in the file system interface).  At the same time, that same object
can be referenced in YET ANOTHER namespace as "README" for export to a
system that expects 8.3 names.

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

#18539

On 11.10.2014 г. 11:06, upsidedown@downunder.com wrote:
 >....
> One aspect that I haven't seen discussed in this thread is that a
> "file" does not necessary have a single "name". While there may be
> physical allocations of blocks on a disk and there might be some kind
> of index file entry for those, there can be multiple directory entries
> with different file or multiple entries in multiple directories
> pointing to the same physical file. Various links and directory
> entries are used  e.g. for user, protection or language specific views
> to create multiple views of a file.
>

In DPS I treat this as an error. It can happen, one could even reproduce
it from a command line (e.g. by copying a directory to another file and 
by leaving the destination copy file type being that of a directory;
will take just a little more typing than normal copy).
But the "repair" function will capture that and will report an error,
the only way around which would be to delete one of the directory
entries pointing to the same (or overlapping) disk areas. [Repair
walks all the directories and builds a new CAT (cluster allocation
table)].
Sometimes this can occur inadvertently, say the system gets reset
before the latest CAT has been updated and some newly allocated
file stays "unallocated". Then upon boot some other file gets
allocated over it (quite a mess really), the fix is to delete
one of the two files.

But copying the directory file can be useful, I have used it
during some rescue missions. Then there is no problem to copy
the directory file as a non-directory type as a sort of backup,
repair will not analyze it then.

Dimiter

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

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

#18542

On 11/10/14 10:06, upsidedown@downunder.com wrote:
> On Fri, 10 Oct 2014 13:43:31 -0700, Don Y <this@is.not.me.com> wrote:
>
>> On 10/10/2014 9:42 AM, Stefan Reuther wrote:
>>> Don Y wrote:
>>>> Does anyone know which filesystem naming constraints are imposed
>>>> in Windows itself vs. the file system layer?  Said another way,
>>>> which constraints are *invariants* regardless of the filesystem?
>>>>
>>>> E.g., can a non-native filesystem redefine '+' to replace "../"?
>>>> Or, allow support for ':' in names?  Or, replace '\' with '/'?
>>>> Or, ...
>>>
>>> Here is what Microsoft has to say on the topic:
>>> http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247%28v=vs.85%29.aspx
>>>
>>> TL;DR, the reserved characters are
>>> - "\", "/" for the path separator
>>> - ":" for the drive letter separator, and to separate file names
>>>     and alternate data streams
>
> I had completely forgotten the NTFS alternate data streams, since at
> least in early NT versions, there were several issues using these
> alternate streams.
>

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.

>
> One aspect that I haven't seen discussed in this thread is that a
> "file" does not necessary have a single "name". While there may be
> physical allocations of blocks on a disk and there might be some kind
> of index file entry for those, there can be multiple directory entries
> with different file or multiple entries in multiple directories
> pointing to the same physical file. Various links and directory
> entries are used  e.g. for user, protection or language specific views
> to create multiple views of a file.
>

In *nix systems, it is normal for there to be a layer of indirection - 
directory entries contain names and point to inodes, and inodes contain 
metadata (ownership, access dates, security flags, etc.) and point to 
lists of datablocks.  It is therefore perfectly normal to have multiple 
directory entries pointing to the same data, and each directory entry 
has equal "status" as the "name" of the file.

Systems can also have additional methods of connecting names to files, 
such as symbolic links.

And on some file systems (such as btrfs), there is another layer of 
indirection beneath inodes so that different files that coincidentally 
share the same data can share the same data blocks, with copy-on-write 
mechanisms used to keep them logically independent.

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

#18553

David Brown wrote:
> On 11/10/14 10:06, upsidedown@downunder.com wrote:
>>> On 10/10/2014 9:42 AM, Stefan Reuther wrote:
>>>> TL;DR, the reserved characters are
>>>> - "\", "/" for the path separator
>>>> - ":" for the drive letter separator, and to separate file names
>>>>     and alternate data streams
>>
>> I had completely forgotten the NTFS alternate data streams, since at
>> least in early NT versions, there were several issues using these
>> alternate streams.
> 
> 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".


  Stefan

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

#18568

On 12/10/14 12:07, Stefan Reuther wrote:
> David Brown wrote:
>> On 11/10/14 10:06, upsidedown@downunder.com wrote:
>>>> On 10/10/2014 9:42 AM, Stefan Reuther wrote:
>>>>> TL;DR, the reserved characters are
>>>>> - "\", "/" for the path separator
>>>>> - ":" for the drive letter separator, and to separate file names
>>>>>      and alternate data streams
>>>
>>> I had completely forgotten the NTFS alternate data streams, since at
>>> least in early NT versions, there were several issues using these
>>> alternate streams.
>>
>> 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!)

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

#18597

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


  Stefan

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

#18598

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

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

#18660

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.

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

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

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

csiph-web