I know what the invalid character sets are for FAT/NTFS/HPFS but is there
some way to query the file system and ask what characters are considered
invalid?
Nope. That’s at least the theoretical purpose of
FSCTL_IS_PATHNAME_VALID (to determine if the characters used are valid)
but notice that in FastFat it is a no-op operation at the current time.
The only thing you can do is try to open files with various characters.
You could, for example, construct a table of valid characters. If this
is something you’d want to use over time, you might consider dynamically
computing it and storing it as a binary key in the registry. You could
even refresh it periodically (e.g., suppose you stored the timestamp on
the FAT file system binary in that binary registry key and then when FAT
changed you recomputed the table). Such a table wouldn’t be terribly
difficult to compute - just start with 0 and go to 65535 trying to open
a file with just that one character name. Mark it FILE_DELETE_ON_CLOSE
and look at the return code, setting the associated bit in your table.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Demetrius Tsitrelis
Sent: Monday, August 01, 2005 8:39 PM
To: ntfsd redirect
Subject: [ntfsd] How to determine valid file path characters for
arbitrary file system?
I know what the invalid character sets are for FAT/NTFS/HPFS but is
there
some way to query the file system and ask what characters are considered
invalid?
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
That would not handle those characters that can only appear within a file
name. Spaces can be embedded, but not leading or trailing. I think the ‘-’
is another exception on some file systems.
“Tony Mason” wrote in message news:xxxxx@ntfsd…
Nope. That’s at least the theoretical purpose of
FSCTL_IS_PATHNAME_VALID (to determine if the characters used are valid)
but notice that in FastFat it is a no-op operation at the current time.
The only thing you can do is try to open files with various characters.
You could, for example, construct a table of valid characters. If this
is something you’d want to use over time, you might consider dynamically
computing it and storing it as a binary key in the registry. You could
even refresh it periodically (e.g., suppose you stored the timestamp on
the FAT file system binary in that binary registry key and then when FAT
changed you recomputed the table). Such a table wouldn’t be terribly
difficult to compute - just start with 0 and go to 65535 trying to open
a file with just that one character name. Mark it FILE_DELETE_ON_CLOSE
and look at the return code, setting the associated bit in your table.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Demetrius Tsitrelis
Sent: Monday, August 01, 2005 8:39 PM
To: ntfsd redirect
Subject: [ntfsd] How to determine valid file path characters for
arbitrary file system?
I know what the invalid character sets are for FAT/NTFS/HPFS but is
there
some way to query the file system and ask what characters are considered
invalid?
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Ah, so we need to have 3 bits per character then, since obviously these
rules will depend upon the file system. One bit to indicate if it is a
valid leading character, one to indicate if it is a valid internal
character, and one to indicate if it is a valid trailing character.
This is, of course, the hazard of designing on the fly when answering
questions like this.
I suspect that we might have to iterate over this a few times, but we
should be able to come up with an algorithm that is sufficiently general
and efficient to work.
Lest my original point be lost, we can argue about ways to achieve this,
but nothing will change the fact that there is no pre-defined mechanism
for doing so.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David J. Craig
Sent: Tuesday, August 02, 2005 2:48 PM
To: ntfsd redirect
Subject: Re:[ntfsd] How to determine valid file path characters for
arbitrary file system?
That would not handle those characters that can only appear within a
file
name. Spaces can be embedded, but not leading or trailing. I think the
‘-’
is another exception on some file systems.
“Tony Mason” wrote in message news:xxxxx@ntfsd…
Nope. That’s at least the theoretical purpose of
FSCTL_IS_PATHNAME_VALID (to determine if the characters used are valid)
but notice that in FastFat it is a no-op operation at the current time.
The only thing you can do is try to open files with various characters.
You could, for example, construct a table of valid characters. If this
is something you’d want to use over time, you might consider dynamically
computing it and storing it as a binary key in the registry. You could
even refresh it periodically (e.g., suppose you stored the timestamp on
the FAT file system binary in that binary registry key and then when FAT
changed you recomputed the table). Such a table wouldn’t be terribly
difficult to compute - just start with 0 and go to 65535 trying to open
a file with just that one character name. Mark it FILE_DELETE_ON_CLOSE
and look at the return code, setting the associated bit in your table.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Demetrius Tsitrelis
Sent: Monday, August 01, 2005 8:39 PM
To: ntfsd redirect
Subject: [ntfsd] How to determine valid file path characters for
arbitrary file system?
I know what the invalid character sets are for FAT/NTFS/HPFS but is
there
some way to query the file system and ask what characters are considered
invalid?
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Tony Mason wrote:
Ah, so we need to have 3 bits per character then, since obviously these
rules will depend upon the file system. One bit to indicate if it is a
valid leading character, one to indicate if it is a valid internal
character, and one to indicate if it is a valid trailing character.
This is, of course, the hazard of designing on the fly when answering
questions like this.
More than that I fear…
D:\foo\bar is valid
D:\f:o\bar is not (usually) valid
There are plenty of cases I could dream up where a character is valid in
one part of the path and not another (eg. $$ in NTFS to specify
streams… must be on the last file element not a directory (IIRC)).
For example… imagine an ssh filesystem…
xxxxx@bar.com:/home/foo
… is a valid path. It’s not too much of a stretch to see that exposed
at kernel level.
Tony
FWIW, the Path.InvalidPathChars field in .NET Framework returns an array of
invalid characters in a pathname. However, they include this caveat:
“The full set of invalid characters can vary by file system. For example, on
Windows-based desktop platforms, invalid path characters might include quote
(”), less than (<), greater than (>), pipe (|), backspace (\b), null (\0),
and Unicode characters 16 through 18 and 20 through 25."
Not too definitive, but a reasonable starting point…
Ken
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tony Hoyle
Sent: Tuesday, August 02, 2005 3:28 PM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] How to determine valid file path characters for
arbitrary file system?
Tony Mason wrote:
Ah, so we need to have 3 bits per character then, since obviously these
rules will depend upon the file system. One bit to indicate if it is a
valid leading character, one to indicate if it is a valid internal
character, and one to indicate if it is a valid trailing character.
This is, of course, the hazard of designing on the fly when answering
questions like this.
More than that I fear…
D:\foo\bar is valid
D:\f:o\bar is not (usually) valid
There are plenty of cases I could dream up where a character is valid in
one part of the path and not another (eg. $$ in NTFS to specify
streams… must be on the last file element not a directory (IIRC)).
For example… imagine an ssh filesystem…
xxxxx@bar.com:/home/foo
… is a valid path. It’s not too much of a stretch to see that exposed
at kernel level.
Tony
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@comcast.net
To unsubscribe send a blank email to xxxxx@lists.osr.com
Actually, now you’ve moved from FSD naming into OS naming, thus opening
up yet another can of worms. NTFS handles colons but not as part of
drive letters. FAT as I recall rejects them. Colon is a valid UNIX
file name character (I know this esoteric fact because I once worked on
a file system that used a colon in the name of its root device), as is *
and ?
The best approach here is to better understand the problem the OP was
trying to solve - perhaps a subset mechanism will work for the caller
(in other words, to simply have a set of rules that will always generate
a valid name) rather than a definitive listing of the rules.
Or maybe the OP should consider using FSCTL_IS_PATHNAME_VALID. It does
only a syntax check on the given name but does appear to be implemented
by most file systems. Aside from that, the OP will need to ask other
questions or provide additional detail.
I think I’m almost done installing that ActiveX control…
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com,
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tony Hoyle
Sent: Tuesday, August 02, 2005 3:28 PM
To: ntfsd redirect
Subject: Re: [ntfsd] How to determine valid file path characters for
arbitrary file system?
Tony Mason wrote:
Ah, so we need to have 3 bits per character then, since obviously
these
rules will depend upon the file system. One bit to indicate if it is
a
valid leading character, one to indicate if it is a valid internal
character, and one to indicate if it is a valid trailing character.
This is, of course, the hazard of designing on the fly when answering
questions like this.
More than that I fear…
D:\foo\bar is valid
D:\f:o\bar is not (usually) valid
There are plenty of cases I could dream up where a character is valid in
one part of the path and not another (eg. $$ in NTFS to specify
streams… must be on the last file element not a directory (IIRC)).
For example… imagine an ssh filesystem…
xxxxx@bar.com:/home/foo
… is a valid path. It’s not too much of a stretch to see that exposed
at kernel level.
Tony
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
> D:\foo\bar is valid
Not a kernel path. A kernel path would be: ??\D:\foo\bar
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
Thanks as always Tony!
“Tony Mason” wrote in message news:xxxxx@ntfsd…
Actually, now you’ve moved from FSD naming into OS naming, thus opening
up yet another can of worms. NTFS handles colons but not as part of
drive letters. FAT as I recall rejects them. Colon is a valid UNIX
file name character (I know this esoteric fact because I once worked on
a file system that used a colon in the name of its root device), as is *
and ?
The best approach here is to better understand the problem the OP was
trying to solve - perhaps a subset mechanism will work for the caller
(in other words, to simply have a set of rules that will always generate
a valid name) rather than a definitive listing of the rules.
Or maybe the OP should consider using FSCTL_IS_PATHNAME_VALID. It does
only a syntax check on the given name but does appear to be implemented
by most file systems. Aside from that, the OP will need to ask other
questions or provide additional detail.
I think I’m almost done installing that ActiveX control…
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com,
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tony Hoyle
Sent: Tuesday, August 02, 2005 3:28 PM
To: ntfsd redirect
Subject: Re: [ntfsd] How to determine valid file path characters for
arbitrary file system?
Tony Mason wrote:
> Ah, so we need to have 3 bits per character then, since obviously
these
> rules will depend upon the file system. One bit to indicate if it is
a
> valid leading character, one to indicate if it is a valid internal
> character, and one to indicate if it is a valid trailing character.
> This is, of course, the hazard of designing on the fly when answering
> questions like this.
>
More than that I fear…
D:\foo\bar is valid
D:\f:o\bar is not (usually) valid
There are plenty of cases I could dream up where a character is valid in
one part of the path and not another (eg. $$ in NTFS to specify
streams… must be on the last file element not a directory (IIRC)).
For example… imagine an ssh filesystem…
xxxxx@bar.com:/home/foo
… is a valid path. It’s not too much of a stretch to see that exposed
at kernel level.
Tony
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com