This is the mail archive of the cygwin-developers 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: CWD and long paths


On 10/13/07, Corinna Vinschen wrote:

> (*) Sorry, Lev, but your idea is too sophisticated from my point of
>     view.  Cygwin would have to create a directory on the fly, create a
>     reparse point on it, and start the child.  Besides of not working on
>     NT4, there's room for collisions.  There's also the problem of how
>     to know when to remove the reparse point and the temporary directory
>     again (aka: are there still grandchildren which might require the
>     reparse point/temp dir?).

FWIW, I had a go at something I thought might be a solution to this:
CreateDirectory(shortpath,NULL);
h=CreateFile(shortpath,GENERIC_WRITE,FILE_SHARE_DELETE,&inheritable,
 OPEN_EXISTING,
  FILE_FLAG_OPEN_REPARSE_POINT|
  FILE_FLAG_BACKUP_SEMANTICS|
  FILE_FLAG_DELETE_ON_CLOSE,
 NULL);
DeviceIoControl(h,FSCTL_SET_REPARSE_POINT,rep,replen,NULL,0,&ret,NULL);
CreateProcess(NULL,cmdline,NULL,NULL,TRUE,0,NULL,shortpath,&si,&pi);

(The idea being that the handle gets inherited by all the
grandchildren, so the delete-on-close behaviour only kicks in after
all grandchildren have quit. I thought this would work because the
children & grandchildren shouldn't notice the pending delete because,
unless they used FILE_FLAG_OPEN_REPARSE_POINT everything they might do
with the directory would actually apply to the target, not the
directory itself, and therefore they won't notice the pending delete.
Apparently this is not how things work :-(  Oh well, it was worth a
try...)

Lev


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