Hi,
I have noticed, first time admittedly, a case where the returned
file name contains a NULL character at the end of the
UNICODE_STRING->Buffer WITHIN the ->Length characters. To date I have
only seen this happen with SharePoint, and very rarely, but often
enough.
E.g. C:\Test\aaa.doc is the file name, and ->Length would be 32
(16*2, whereas there are 15 characters in the name)
Is this a bug in SharePoint, or was I really sleepy in a class?
–
Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
http://www.alfasp.com
File system audit, security and encryption kits.
It’s the responsibility of the file system to refuse names with embedded nulls if they don’t wish to handle them. NTFS and FAT both do this, but the registry (I know, it’s not a file system, but similar) does not.
So there’s certainly no OS prohibition against it. Just sounds a bit peculiar and more likely unintentional.
Tony
OSR
It also depends which minifilters are installed in the system, because some
of them can cache invalid filenames from GenerateFileNameCallback routine. I
use debug assert macro for unicode string which checks also null character
at Length-1 position, but it was always my fault.
Well, the “underlying” file system is NTFS, but the NULL is probably removed on the server side, since the I/O works.
However, it does appear on the client side (WebDav).
@Petr, how was it your fault? It might give me a clue.
Though I currently use the file name directly from FltMgr’s FLT_FILE_NAME_INFROMATION without changing it at all, so the NULL was there.
Tony Mason wrote:
It’s the responsibility of the file system to refuse names with embedded nulls if they don’t wish to handle them. NTFS and FAT both do this, but the registry (I know, it’s not a file system, but similar) does not.
So there’s certainly no OS prohibition against it. Just sounds a bit peculiar and more likely unintentional.
–
Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
http://www.alfasp.com
File system audit, security and encryption kits.