std.path.getName(): Screwy by design?

[Nick Sabalausky]

"Don" <nospam at nospam.com> wrote in message 
news:ikj7n9$1sg2$1 at digitalmars.com...
> Steven Schveighoffer wrote:
>> On Tue, 01 Mar 2011 09:01:49 -0500, Nick Sabalausky <a at a.a> wrote:
>>>
>>> People don't always realize it, but Windows really is the same way. It's
>>> really only the user-level applications like Explorer that ever care 
>>> about
>>> "extension", and even then the extension is always just "everything 
>>> after
>>> the last dot in the filename". Anything beyond that is merely tradition 
>>> and
>>> convention. The only real difference is that windows has no standard
>>> mechanism for looking at the content of the file to help determine its 
>>> type.
>
> No, it tries hard to make it look that way, but it's evolved from a system 
> where extensions were fundamental.
> Even now, an 8.3 filename still exists for every file.
>

The existence of an 8.3 fallback doesn't really have any bearing on it. And 
neither does pedigree. If there is still a fundamental distinction with 
extension, it's nothing more than a detail of how the filesystem spec 
defines its data storage and completely abstracted away by the filesystem 
driver.

Name one case in windows where some sort of distinction between filename and 
extension actually makes a real tangible difference versus unix, that 
doesn't merely amount to convention (there's zero technical hurdle in the 
way of a windows program considering ".bashrc" to be extensionless) or 
manually re-implementing part of the filesystem spec (heck, unix has FAT32 
and NTFS drivers, too).