tar: NTFS ADS case?

[woodruffw]

This is another weird one, not sure what category it falls under: NTFS has alternate data streams, e.g. opening foo.txt:bar creates an ADS on foo.txt with contents that are distinct from foo.txt.

I think in practice this means that a tar member that accidentally (or intentionally) has a colon in its name will create an ADS, rather than a verbatim file with that name.

I suspect that a hardened tar extractor should reject these names as invalid, since they probably don't represent (honest) user intent. But I'm not 100% sure, since they're arguably just another form of file and a tar extractor can't possibly handle all of the ways in which host FSes do things like ADSes/resource forks/etc.

[woodruffw]

(I suspect you already knew all this! But it might be useful to have a malo tar case for it too 🙂)

[thatch]

I currently don't have ~any of the Windows specific items, you're right. For knowledge of how filesystems behave, I don't want to rely on GHA, so I have a local Windows PE image that is close to working -- I'd love to note whether normalization happens on write or read, for example, and if the capitalization can change if you open an already-existing file for writing (but with different capitalization). Thanks for the reminder.

(The "vulerable_when" json was kind of a stopgap, some of these items actually do have to hit the filesystem... and the oracles that end up doing a decent job are an example of the kind of validation that you, the application, are intended to perform when using the library. If you have better ideas here, please do.)