[SOLVED] Un-allowed characters in filenames

273 · 12-08-2014, 03:06 PM

So the old "FAT32" file name aliases were preserved in NTFS? I don't see how that affects the NTFS file name? Since around Windows 2000 file and directory names have allowed almost as many characters as Linux.
As to the original point of my previous post -- having messed with various file systems under Windows I tend to take MS's word for it that the problem with the colon is due to "streams". I, too, see no evidence of them being implemented -- hence my speculation they were dropped due to lack of fund or time or just due to them being a feature of something MS bought or stole which they saw no further use for.

Doc CPU · 12-08-2014, 03:24 PM

Hi there,

Quote:

Originally Posted by Ser Olmy

While anything can be stored in an NTFS Alternate Data Stream, they are most commonly used for storing metadata. For instance, when a file is downloaded from the Internet and saved on an NTFS volume, Windows will store information about the file's origin ("zone") in an ADS called "Zone.Identifier".

that's a terrific bit of information, thanks for the insight!
In fact, when I had to use a Windows PC, I often wondered how Windows could "know" that a particular file had been downloaded from the internet. Now that explains a lot.

Quote:

Originally Posted by 273

So the old "FAT32" file name aliases were preserved in NTFS?

Yes, but exactly the other way round. NTFS considered the "long names" as the primary file names from the start, and for those infamous "compatibility reasons" still maintained the old 8.3 file names for applications that seemed to expect them.

Quote:

Originally Posted by 273

I don't see how that affects the NTFS file name? Since around Windows 2000 file and directory names have allowed almost as many characters as Linux.

That's right, in advancing from Windows 4 to Windows 5, the set of allowed characters in NTFS file names was liberalized greatly. And with SP6, AFAIR, even the ancient and senile Windows NT4 got that benefit retroactively.

[X] Doc CPU

Ser Olmy · 12-08-2014, 03:27 PM

Quote:

Originally Posted by Doc CPU

it's much more obvious and dates back to the stone age of DOS, where the colon was used to separate a device name (most frequently a drive letter) from the actual path or parameters. Windows has just dragged along that legacy ever since.

While it's true that the colon is used to separate the drive letter from the file path, it was not required for device names, and still isn't. This can lead to some very interesting bugs. For instance, the device name for STDOUT is "con" on the DOS/Windows platform:

Code:

C;\Users\Test> echo This is a test > con:
This is a test
C:\Users\Test> _

And the > redirection operator clearly works as it does on the various *NIX platforms:

Code:

C:\Users\Test> echo This is a test > test.txt
C:\Users\Test> dir
 Volume in drive C has no label.
 Volume Serial Number is 1234-5678

 Directory of C:\Users\Test

08.12.2014  22:16    <DIR>          .
08.12.2014  22:16    <DIR>          ..
08.12.2014  22:16                17 test.txt
               1 File(s)             17 bytes
               2 Dir(s)  875*249*891*328 bytes free

C;\Users\Test> _

But as it turns out, "con" is a reserved name, and no device qualifier is required:

Code:

C:\Users\Test> echo Foo! > C:\Users\Test\con.txt
Foo!

C:\Users\Test> echo Foo! > C:\Users\Test\prn.txt
The system cannot find the file specified.

C:\Users\Test> What the...?_

So on the Windows platform, devices like con, lst, comn, lptn, nul and a few others appear to be invisible files existing (or not, as the case may be for prn) in every directory of every mounted file system.

Fixit7 · 12-10-2014, 11:44 AM

Streams in Windows allows hidden files that most users are unaware of.

http://www.osronline.com/article.cfm?article=457