I understand that non ADS.aware applications can not view the
streams' files, but for apps that *are* ADS aware: Can they see the
streams as files if they have the ability built in?
As files without any more qualification, no.
They would always be referenced using either the colon-separated
format 'name:stream' (typically if you are passing a stream name to
compiled application, or if you already know the name of a stream) or
by using special API functions (if you are scanning for unknown
streams). The functions are able to extract all of the stream names
and stream data given the standard name of the file (first you get a
handle to the file by name, _then_ you loop through its streams,
reinforcing the parent-child kind of relationship I've been trying to
put across).
These data streams must be stored somewhere after all... For
example, if I have a 1GB HD and I fill 900MB of it with an alternate
data stream, I can only have 100MB left, but in what form of data do
the 900MB appear to for example checkdisk as a non ADS aware
application?
Chkdsk *will not* increment the number of files if you add ADSes to a
given file. It "will" see that there are more allocation units in use
on the disk.
And is it possible to see the 900MB file for an ADS aware
application as a real file that can be located in an 'alternate
directory' or something?
No.
An ADS-aware application must still treat ADSes as ADSes. They are not
simple files. Either the colon-separated syntax or the ADS-aware API
functions must be used.
For my 'classical file oriented :-)' understanding all data,
alternate or not, should be locatable somewhere as a file or
something else from an ADS aware application. Or is this classic
view on these things the wrong approach for ADS?
Wherever your classic view is taking you is obvs. causing too much
confusion for a pretty simple, albeit cool, technology. I think your
view is too rooted in the (mis)apprehension that discrete files are
"real" or "physical" -- as opposed to being arbitrary constructs of
the particular filesystem in use that allow assemblages of bytes to be
viewed as discrete wholes. Try accessing an NTFS partition as if it
were FAT32; you'll see that _all_ your files are suddenly un-"real",
not just the ADSes!
ADSes are definitely present on disk in physically separate (and quite
possibly discontiguous) areas, just like primary data streams. You can
see that they take up allocation units, just like anything else that
gets saved. Major, really only, diff is that they don't have their own
standalone names, being only addressable as subnames of a "master"
file. This ensures that ADSes, which typically provide supporting
data, such as user settings, or store state, as with the SMTP queue,
will be deleted along with the (sole) data to which they relate.
--Sandy