2009/4/8 Peter Rosin peda@lysator.liu.se:
Hi!
[I just subscribed, I hope I got the forged in-reply-to header right]
Ben Klein wrote:
This is what I meant about magic translation. It *shouldn't* work, but I'm aware that it does. DOS/Windows uses backslash as the delimiter when reporting and storing paths. Is the behaviour of magic translation from foreslash to backslash documented (by Microsoft) anywhere?
From: http://msdn.microsoft.com/en-us/library/aa365247.aspx
- MSDN Library
+ Win32 and COM Development + System Services + File Services + File Systems + File Management + About File Management + Creating, Deleting, and Maintaining Files * File Names, Paths, and Namespaces
"Note File I/O functions in the Windows API convert "/" to "" as part of converting the name to an NT-style name, except when using the "\?" prefix as detailed in the following sections."
So, the Win32 API supports /
BTW, people using the identity mount technique with MinGW (*) are not unlikely to have a /bin/sh on the current drive. Hmmm, but that's actually /bin/sh.exe so maybe they are safe? And I guess building mingw-gcc on Windows isn't "real work" (that's the main reason for the identiy mount, IIUC). Anyway, that's just another stab at the python test suite.
Building stuff using MSYS/MinGW (or Cygwin) inside wine which requires an identity mount is surely just for fun. Anything MSYS or Cygwin inside Wine is for fun. The identity mount technique clearly does not work with Wine.
Cheers, Peter
(*) Google: mingw "identity mount"
This is probably a really dumb question... but why does wine support UNIX paths? What is the circumstance where a Windows application will be trying to access a native file or directory? The only example I can think of is that an app has specifically been written to be used in Wine, in which case, shouldn't native UNIX paths be disabled by default, and perhaps turned on with an environment variable?
Luke.