Actually, that's quite easy. Use the \\?\... syntax to override the Win32
filename processing. This also gets around limitations like not being able
to create a file named "com1" or "null".
For more information on this, check the docs on CreateFile, which describe
the \\?\ prefix. Basically, if CreateFile sees that its filename argument
begins with \\?\, then it will scan over (ignore) the prefix, and pass the
rest of the path directly to NtCreateFile (the internal / native API), and
will use the RootDirectory handle (in ObjectAttributes) to identify the \??
kernel directory namespace. This lets you do a lot of fun stuff.
HOWEVER, a lot of other parts of the Win32 subsystem will NOT properly
support this. For example:
[D:\temp\example] dir
Volume in drive D is Data
Volume Serial Number is XXXX-XXXX
Directory of D:\temp\example
01/20/2006 04:19 PM <DIR> .
01/20/2006 04:19 PM <DIR> ..
0 File(s) 0 bytes
2 Dir(s) 186,969,300,992 bytes free
[D:\temp\example] echo foo >\\?\d:\temp\example\foo...
[D:\temp\example] dir
Volume in drive D is Data
Volume Serial Number is XXXX-XXXX
Directory of D:\temp\example
01/20/2006 04:19 PM <DIR> .
01/20/2006 04:19 PM <DIR> ..
01/20/2006 04:19 PM 6 foo...
1 File(s) 6 bytes
2 Dir(s) 186,969,300,992 bytes free
[D:\temp\example] type foo...
The system cannot find the file specified.
[D:\temp\example] del foo...
Could Not Find D:\temp\example\foo...
[D:\temp\example] type \\?\d:\temp\example\foo...
foo
[D:\temp\example] del \\?\d:\temp\example\foo...
[D:\temp\example]
So, while it IS possible (and easy) to create files on Windows systems that
do not conform to the Win32 rules (which exist only for compatibility with
applications), it may not be terribly useful, because most applications do
NOT use the \\?\ syntax, and therefore will not be able to manipulate the
files that you create.
I agree with Max. It's a bad idea, mostly because of the potential for
causing problems that most users will be completely unable to fix (filenames
that cannot be manipulated with ordinary tools and programs).
-- arlie
-----Original Message-----
From: Max Bowsher [mailto:maxb1@ukf.net]
Sent: Friday, January 20, 2006 3:58 PM
To: von Löwis Martin
Cc: dev@subversion.tigris.org
Subject: Re: Files with trailing dots on Windows
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
von Löwis Martin wrote:
> I would like subversion to support files with trailing dots on Windows.
Well, you'd better go and convince Microsoft to make Windows to support
filenames with trailing dots, then.
> One use case for that is
>
> http://svn.python.org/projects/python/trunk/Mac/IDE%20scripts/
>
> where "Insert folder name..." has trailing dots. On checking out the
> tree, subversion creates a file "Insert folder name" instead, and
> subsequently reports that the tree was modified (with the original
> file missing). svn revert will try to create the missing file, but
> fail just as the original checkout failed.
Some kind of mapping logic to avoid the bizarre restrictions on Windows file
naming isn't totally out of the question, but that's a very different topic.
> However, there are solutions/work-arounds available, which I think
> subversion should use.
>
> For this specific problem, escaping the path name with \\?\ would
> help. To see how this works, try running
>
> notepad.exe \\?\c:\foo.txt...
>
> This will happily create a file with trailing dots in ist name;
> Microsoft even documents it in the Win32 API (somewhere).
>
> May I file a bug report for that issue?
>
> Regards,
> Martin
>
> P.S. If you were interested in supporting case-sensitive file names
> also (i.e. having two files in the same directory that only differ in
> case): that would be possible through FILE_FLAGS_POSIX_SEMANTICS for
> CreateFile - unfortunately, you would have to use NtDeleteFile for
> removal...
Sure, you can play all sorts of devious tricks with low level APIs, but that
leaves you with files on your disk that cause 99% of existing software tools
to then break in mysterious ways when you attempt to work with them.
In my personal opinion, this 'solution' is totally nonviable.
Max.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)
iD8DBQFD0U7bfFNSmcDyxYARAkH+AKCjNJXlBKMeA6Q8cpnN0UNH4k1C8QCfZtKr
dfcvWhJE7QzS8+JS1akJLIk=
=L5mE
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jan 20 22:22:14 2006