This is the mail archive of the cygwin-patches@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch] unlink


At 06:47 PM 10/31/2004 -0500, you wrote:
>On Sun, Oct 31, 2004 at 10:14:48AM -0500, Pierre A. Humblet wrote:
>>At 11:36 PM 10/30/2004 -0400, Christopher Faylor wrote:
>>>On Sat, Oct 30, 2004 at 10:30:54PM -0400, Pierre A. Humblet wrote:
>>>>At 01:39 PM 10/30/2004 -0400, you wrote:
>>>>>On Fri, Oct 29, 2004 at 06:01:51PM -0400, Pierre A. Humblet wrote:
>>>>>>Here is a patch that should allow unlink() to handle
>>>>>>nul etc.. on local disks.
>>>>>>
>>>>>>It's a cut and paste of Corinna's open on NT and the
>>>>>>existing CreateFile.
>>>>>> 
>>>>>>It works on normal files. I haven't tested with the
>>>>>>special names because I forgot how to create them !
>>>>>>Feedback welcome.
>>>>>>
>>>>>>XXXXX This should NOT be applied in 1.5.12 XXXXXX
>>>>>>
>>>>>>Pierre
>>>>>>
>>>>>>2004-10-29  Pierre Humblet <pierre.humblet@ieee.org>
>>>>>>
>>>>>>	* syscalls.cc (nt_delete): New function.
>>>>>>	(unlink): Call nt_delete instead of CreateFile and remove
>>>>>>	unreachable code.
>>>>>
>>>>>Corinna suggested something similar to me a couple of months ago but I
>>>>>wanted to wait for things to settle down somewhat after the original
>>>>>use of NtCreateFile.
>>>>>
>>>>>On reflection, however, wouldn't it be a little easier just to prepend
>>>>>the path being deleted with a: \\.\ so that "rm nul" would eventually
>>>>>translate to DeleteFile("\\.\c:\foo\null") (I'm not using true C
>>>>>backslash quoting here)?  I don't know if that would work on Windows 9x,
>>>>>though.
>>>>
>>>>That would work on NT, but then one would need to check if the input
>>>>path didn't already have the form //./xx, worry about exceeding max 
>>>>pathlength, etc...
>>>
>>>Other than being able to delete special filenames is there any other
>>>benefit to using NtCreateFile to delete files?
>>
>>I can only think of speed. But I don't see a downside either, given that
>>we use it in open().
>>
>>>If path length was an issue we could use '//?/' instead since the length
>>>restriction is a lot larger there.  So, it would be something like:
>>>
>>>  char *path;
>>>  char newpath[strlen (win32_name) + 4] = "\\\\?\";
>>>  if  (win32_name[0] != '\\')
>>>      path = strcat (newpath, win32_name);
>>>  else
>>>      path = win32_name;
>>>
>>>and then you'd use path throughout from then on.
>>
>>Have you tried it? According to MSDN you need to use the Unicode version
>>if you do that.
>
>Yes.  I created and deleted a file using '//?/d:/nul' from the command line.

It's interesting that //?/ also works as an escape with the ascii version.
But on re-reading MSDN, the unicode version should only be needed when
the pathlength exceeds 260 chars.
BTW, don't try that on WinME. I ended up having to power the PC down.

Pierre


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]