Vista - Tag only some file types

Was disappointed to read TXT files cannot be tagged.
Guess I'll not be able to tag many of the files I wanted to
e.g. html, vbs, bat. (still waiting for vista upgrade)

Is there a list of common file types that can and can't be tagged?
Searched Google but found nothing.

On Mon, 02 Apr 2007 15:33:57 +1000, Daniel Noll <daniel@nuix.com>
>cquirke (MVP Windows shell/user) wrote:

>>> This annoys me too. Under XP we used to be able to add metadata to any
>>> file, even text files. Something like that might even make the search
>>> functionality useful, as it would allow you to search by tag on
>>> arbitrary files.
>>
>> Depends where the tags go, I guess - some file formats contain tag
>> fields, whereas with text, every part of the file is content.
>>
>> So, to tag a text file without botching the content or breaking its
>> text "purity", it would have to write to an ADS, add a companion file
>> (e.g. the way .PIF hold properties for DOS apps) or store it in some
>> sort of database - all of which are ugly, for various reasons.
>
>Ugly, yes... but it's the way it was done in XP -- an ADS was
>constructed containing the metadata. So now we have all these streams
>containing metadata which Vista can't even access.

Vista can access ADS; whether it was written to do so is another
thing. There are very good reasons to leave ADS alone.

>The nice thing about it using ADS is that it worked silently via Samba
>-- it would just create a file on the other end with the colon and the
>stream name. Nice and easy to back up. :-)

ADS are a death-trap, because:
- the UI doesn't show them, so you have no control over them
- they can be automated as easily as via a batch file
- MS will happily run code hidden in them, by design
- code in an ADS takes the file name of the host file
- so Ctl+Alt+Del lists only the host file, not the ADS
- so firewalls checking only the host file, let ADS pass through
- most off-NTFS transfers strip the ADS, so...
- ...submitting ADS samples to av vendors is difficult

MS could have prevented code from running from an ADS, or filtered ADS
input to ensure only text was permitted, or provided a UI for ADS, or
done all of these risk-aware, clueful things. They did none of them.

Who needs a rootkit, when content within ADS is invvisible, by design?

The cure for ADS is FATxx ;-)


>-- Risk Management is the clue that asks:
"Why do I keep open buckets of petrol next to all the
ashtrays in the lounge, when I don't even have a car?"
>----------------------- ------ ---- --- -- - - - -

Weong. ADS is built into OLE Compound files. So Doc, Xls, Mdb, Pps, et al
all support this. Technically it isn't an ADS as OLE files have a file
system built in. ADS replicates for non OLE files what OLE files have. So
Fat is no protection. Just put an ole file on disk with whatever you want in
the PLE file as a file (ole files are a file system, sub directories etc -
the file system merely resides in a single file).
"cquirke (MVP Windows shell/user)" <cquirkenews@nospam.mvps.org> wrote in
message news:gpe2131ms2cuigl5sta83t5vk7u66hvk1s@4ax.com...
> On Mon, 02 Apr 2007 15:33:57 +1000, Daniel Noll <daniel@nuix.com>
>>cquirke (MVP Windows shell/user) wrote:
>
>>>> This annoys me too. Under XP we used to be able to add metadata to any
>>>> file, even text files. Something like that might even make the search
>>>> functionality useful, as it would allow you to search by tag on
>>>> arbitrary files.
>>>
>>> Depends where the tags go, I guess - some file formats contain tag
>>> fields, whereas with text, every part of the file is content.
>>>
>>> So, to tag a text file without botching the content or breaking its
>>> text "purity", it would have to write to an ADS, add a companion file
>>> (e.g. the way .PIF hold properties for DOS apps) or store it in some
>>> sort of database - all of which are ugly, for various reasons.
>>
>>Ugly, yes... but it's the way it was done in XP -- an ADS was
>>constructed containing the metadata. So now we have all these streams
>>containing metadata which Vista can't even access.
>
> Vista can access ADS; whether it was written to do so is another
> thing. There are very good reasons to leave ADS alone.
>
>>The nice thing about it using ADS is that it worked silently via Samba
>>-- it would just create a file on the other end with the colon and the
>>stream name. Nice and easy to back up. :-)
>
> ADS are a death-trap, because:
> - the UI doesn't show them, so you have no control over them
> - they can be automated as easily as via a batch file
> - MS will happily run code hidden in them, by design
> - code in an ADS takes the file name of the host file
> - so Ctl+Alt+Del lists only the host file, not the ADS
> - so firewalls checking only the host file, let ADS pass through
> - most off-NTFS transfers strip the ADS, so...
> - ...submitting ADS samples to av vendors is difficult
>
> MS could have prevented code from running from an ADS, or filtered ADS
> input to ensure only text was permitted, or provided a UI for ADS, or
> done all of these risk-aware, clueful things. They did none of them.
>
> Who needs a rootkit, when content within ADS is invvisible, by design?
>
> The cure for ADS is FATxx ;-)
>
>
>>-- Risk Management is the clue that asks:
> "Why do I keep open buckets of petrol next to all the
> ashtrays in the lounge, when I don't even have a car?"
>>----------------------- ------ ---- --- -- - - - -

Plus OLE is used by default by the shell if no registered file type for a
file. And OLE is used by default for OLE files by programs opening files via
OLE.
<.> wrote in message news:OaCgFqgdHHA.4004@TK2MSFTNGP06.phx.gbl...
> Weong. ADS is built into OLE Compound files. So Doc, Xls, Mdb, Pps, et al
> all support this. Technically it isn't an ADS as OLE files have a file
> system built in. ADS replicates for non OLE files what OLE files have. So
> Fat is no protection. Just put an ole file on disk with whatever you want
> in the PLE file as a file (ole files are a file system, sub directories
> etc - the file system merely resides in a single file).
> "cquirke (MVP Windows shell/user)" <cquirkenews@nospam.mvps.org> wrote in
> message news:gpe2131ms2cuigl5sta83t5vk7u66hvk1s@4ax.com...
>> On Mon, 02 Apr 2007 15:33:57 +1000, Daniel Noll <daniel@nuix.com>
>>>cquirke (MVP Windows shell/user) wrote:
>>
>>>>> This annoys me too. Under XP we used to be able to add metadata to
>>>>> any
>>>>> file, even text files. Something like that might even make the search
>>>>> functionality useful, as it would allow you to search by tag on
>>>>> arbitrary files.
>>>>
>>>> Depends where the tags go, I guess - some file formats contain tag
>>>> fields, whereas with text, every part of the file is content.
>>>>
>>>> So, to tag a text file without botching the content or breaking its
>>>> text "purity", it would have to write to an ADS, add a companion file
>>>> (e.g. the way .PIF hold properties for DOS apps) or store it in some
>>>> sort of database - all of which are ugly, for various reasons.
>>>
>>>Ugly, yes... but it's the way it was done in XP -- an ADS was
>>>constructed containing the metadata. So now we have all these streams
>>>containing metadata which Vista can't even access.
>>
>> Vista can access ADS; whether it was written to do so is another
>> thing. There are very good reasons to leave ADS alone.
>>
>>>The nice thing about it using ADS is that it worked silently via Samba
>>>-- it would just create a file on the other end with the colon and the
>>>stream name. Nice and easy to back up. :-)
>>
>> ADS are a death-trap, because:
>> - the UI doesn't show them, so you have no control over them
>> - they can be automated as easily as via a batch file
>> - MS will happily run code hidden in them, by design
>> - code in an ADS takes the file name of the host file
>> - so Ctl+Alt+Del lists only the host file, not the ADS
>> - so firewalls checking only the host file, let ADS pass through
>> - most off-NTFS transfers strip the ADS, so...
>> - ...submitting ADS samples to av vendors is difficult
>>
>> MS could have prevented code from running from an ADS, or filtered ADS
>> input to ensure only text was permitted, or provided a UI for ADS, or
>> done all of these risk-aware, clueful things. They did none of them.
>>
>> Who needs a rootkit, when content within ADS is invvisible, by design?
>>
>> The cure for ADS is FATxx ;-)
>>
>>
>>>-- Risk Management is the clue that asks:
>> "Why do I keep open buckets of petrol next to all the
>> ashtrays in the lounge, when I don't even have a car?"
>>>----------------------- ------ ---- --- -- - - - -
>

cquirke (MVP Windows shell/user) wrote:
> ADS are a death-trap, because:
> - the UI doesn't show them, so you have no control over them

XP used to have this UI to modify the metadata, Vista removed it. This
is basically what I've been complaining about.

The UI in XP was useful: if the document happened to be a real OLE2
document it showed you the summary information from inside the OLE2
filesystem. If it wasn't an OLE2 document (e.g. if it was a text file)
then it showed the summary information from the ADS. The upshot is that
ultimately any file can have things like an Author set. You can kiss
that functionality goodbye in Vista (it won't even let you view the
metadata you already spent ages painstakingly creating under XP.)

> MS could have prevented code from running from an ADS, or filtered ADS
> input to ensure only text was permitted, or provided a UI for ADS, or
> done all of these risk-aware, clueful things. They did none of them.

This is all true but completely irrelevant to the topic of discussion,
which is regarding the (prior) use of ADS to store METADATA, not
arbitrary executable crap.

Daniel

I don't have any to test. Is it shown in Explorer's columns.
"Daniel Noll" <daniel@nuix.com> wrote in message
news:uY0QgWydHHA.596@TK2MSFTNGP06.phx.gbl...
> cquirke (MVP Windows shell/user) wrote:
>> ADS are a death-trap, because:
>> - the UI doesn't show them, so you have no control over them
>
> XP used to have this UI to modify the metadata, Vista removed it. This is
> basically what I've been complaining about.
>
> The UI in XP was useful: if the document happened to be a real OLE2
> document it showed you the summary information from inside the OLE2
> filesystem. If it wasn't an OLE2 document (e.g. if it was a text file)
> then it showed the summary information from the ADS. The upshot is that
> ultimately any file can have things like an Author set. You can kiss that
> functionality goodbye in Vista (it won't even let you view the metadata
> you already spent ages painstakingly creating under XP.)
>
>> MS could have prevented code from running from an ADS, or filtered ADS
>> input to ensure only text was permitted, or provided a UI for ADS, or
>> done all of these risk-aware, clueful things. They did none of them.
>
> This is all true but completely irrelevant to the topic of discussion,
> which is regarding the (prior) use of ADS to store METADATA, not arbitrary
> executable crap.
>
> Daniel
>

Right click a MSI file (Windows Installer file) and choose Properties. I'm
not sure if it is an ADS or an Installer metadata editor. I research it one
day and know.
"Daniel Noll" <daniel@nuix.com> wrote in message
news:uqRo4hOdHHA.2268@TK2MSFTNGP02.phx.gbl...
> cquirke (MVP Windows shell/user) wrote:
>>> This annoys me too. Under XP we used to be able to add metadata to any
>>> file, even text files. Something like that might even make the search
>>> functionality useful, as it would allow you to search by tag on
>>> arbitrary files.
>>
>> Depends where the tags go, I guess - some file formats contain tag
>> fields, whereas with text, every part of the file is content.
>>
>> So, to tag a text file without botching the content or breaking its
>> text "purity", it would have to write to an ADS, add a companion file
>> (e.g. the way .PIF hold properties for DOS apps) or store it in some
>> sort of database - all of which are ugly, for various reasons.
>
> Ugly, yes... but it's the way it was done in XP -- an ADS was constructed
> containing the metadata. So now we have all these streams containing
> metadata which Vista can't even access.
>
> The nice thing about it using ADS is that it worked silently via Samba --
> it would just create a file on the other end with the colon and the stream
> name. Nice and easy to back up. :-)
>
> Daniel
>

On Wed, 4 Apr 2007 02:09:36 +1000, <.> wrote:

>Weong.

What is "weong"?

If you're going to top-post, then you have to contextualize.

>ADS is built into OLE Compound files. So Doc, Xls, Mdb, Pps, et al
>all support this. Technically it isn't an ADS as OLE files have a file
>system built in. ADS replicates for non OLE files what OLE files have.

In other words, it's not ADS at all, just something within a normal
file that works in similar ways.

>So FATxx is no protection.

I didn't say FATxx was a protection against OLE. I said it's a
protection against ADS, and it is - but it's good to highlight other
content embedding opportunities like OLE, archives, mailboxes, .PST,
..EML files and the re-packing of executables themselves.

>Just put an ole file on disk with whatever you want in the
>PLE file as a file (ole files are a file system, sub directories etc -
>the file system merely resides in a single file).

Thanks for the heads up; I've never considered OLE as a file system
capable of directories etc. I thought it merely embedded content
within other files, but it seems as if it is more like archives than I
would have expected... and now, let us search...

http://support.microsoft.com/kb/83659

http://www.cs.toronto.edu/~delara/pa...tml/node5.html

http://en.wikipedia.org/wiki/Object_..._and_Embedding

Unfortunately, these results of Search( OLE format ) don't really go
into the binary structure, neither do they mention internal
equivalents of directories and subtrees.

Several file types are "tagged" in that the sort of info that
populates "properties" can be stored there. XML generalizes this to
include "lumpier" content, and the the middle of those links implies
this will grow to eclipse OLE. The Wikipedia article includes a
reminder of why one often has to click Flash content twice.

>"cquirke (MVP Windows shell/user)" wrote:

>> The cure for ADS is FATxx ;-)



>-------------------- ----- ---- --- -- - - - -
Tip Of The Day:
To disable the 'Tip of the Day' feature...
>-------------------- ----- ---- --- -- - - - -

In a Resource Kit or PSDK tools there is DocViewer which is a file system
view of an OLE compound file.

weong - I can't see the keyboard,

"cquirke (MVP Windows shell/user)" <cquirkenews@nospam.mvps.org> wrote in
message news:idtc13t64tub5hjr0mshosjd93kef4jk24@4ax.com...
> On Wed, 4 Apr 2007 02:09:36 +1000, <.> wrote:
>
>>Weong.
>
> What is "weong"?
>
> If you're going to top-post, then you have to contextualize.
>
>>ADS is built into OLE Compound files. So Doc, Xls, Mdb, Pps, et al
>>all support this. Technically it isn't an ADS as OLE files have a file
>>system built in. ADS replicates for non OLE files what OLE files have.
>
> In other words, it's not ADS at all, just something within a normal
> file that works in similar ways.
>
>>So FATxx is no protection.
>
> I didn't say FATxx was a protection against OLE. I said it's a
> protection against ADS, and it is - but it's good to highlight other
> content embedding opportunities like OLE, archives, mailboxes, .PST,
> .EML files and the re-packing of executables themselves.
>
>>Just put an ole file on disk with whatever you want in the
>>PLE file as a file (ole files are a file system, sub directories etc -
>>the file system merely resides in a single file).
>
> Thanks for the heads up; I've never considered OLE as a file system
> capable of directories etc. I thought it merely embedded content
> within other files, but it seems as if it is more like archives than I
> would have expected... and now, let us search...
>
> http://support.microsoft.com/kb/83659
>
> http://www.cs.toronto.edu/~delara/pa...tml/node5.html
>
> http://en.wikipedia.org/wiki/Object_..._and_Embedding
>
> Unfortunately, these results of Search( OLE format ) don't really go
> into the binary structure, neither do they mention internal
> equivalents of directories and subtrees.
>
> Several file types are "tagged" in that the sort of info that
> populates "properties" can be stored there. XML generalizes this to
> include "lumpier" content, and the the middle of those links implies
> this will grow to eclipse OLE. The Wikipedia article includes a
> reminder of why one often has to click Flash content twice.
>
>>"cquirke (MVP Windows shell/user)" wrote:
>
>>> The cure for ADS is FATxx ;-)
>
>
>
>>-------------------- ----- ---- --- -- - - - -
> Tip Of The Day:
> To disable the 'Tip of the Day' feature...
>>-------------------- ----- ---- --- -- - - - -

On Sat, 7 Apr 2007 04:25:57 +1000, <.> wrote:

>In a Resource Kit or PSDK tools there is DocViewer which is a file system
>view of an OLE compound file.

Thanks! I'm going to try and search for that, but in case I can't
resolve a link to it, can you URL me or give me the tool's name?

>weong - I can't see the keyboard,

I know how that goes :-)

Murphy's 1.17.1066 variation: If you are going to make a typo, it will
be when flaming somebody, especially when typing a "typo" flame

Hence the tag...



>-------------------- ----- ---- --- -- - - - -
Trsut me, I won't make a mistake!
>-------------------- ----- ---- --- -- - - - -