> Alexandre Julliard wrote:
> > The right fix IMO is to make chdir() follow 
> SetCurrentDirectory(), so
> > that the Unix and Windows curdirs are always in sync. This will
> > require some hacking in the 16-bit task switching (since the 16-bit
> > curdir is per-task, not per-process). Maybe in the meantime 
> we should
> > remove the chdir("/"), it seems to cause more problems than 
> it fixes;
> > and maybe this will encourage Marcus to implement the right 
> solution ;-)

Probably. Personally, I was suprised that you let this hack in. :-)

> One problem with this is that DOS/Windows keeps the current 
> directory on a per
> drive basis (at least from a user interface point of view, 
> don't know how it is
> implemented internally).  Of course since you also know the 
> current (aka
> default) drive as well as the current directory you can 
> change the current
> UNIX dir when the drive is changed.

This is a question about how relative and absolute paths
are resolved, not an issue about which is the current
directory.

Each thread has one and only one current directory.

> However I could see this 
> causing problems
> if a process's current directory is a CD-ROM drive it will prevent the
> CD-ROM from being unmounted.  That is both good and bad.  
> Under DOS it is
> perfectly valid to eject the CD-ROM even if you are on that 
> drive.  Under
> Windows it will generally give you a message about the drive 
> being in use and
> ask if you want to eject it anyway.

Whether this should be permitted or not is IMHO policy which
should be determined for each system by the system administrator,
since allowing this is potentially dangerous (OK for a CD-ROM
or other read only devices not much can happen but still).

However I'm not sure this a matter of Wine policy, I think
it lies more in the direction of the policy of Unix system.

Wine must of course gracefully handle the case when the directory
disappears under our feet because of forced unmounting of a 
mountpoint, but that is a different issue.

> I am not exactly sure how to deal with this extremely screwed 
> up behavior.  Of
> course that is the story of Wine so what else is new.

I'm not either, however I'm inclined to believe that we really
can't solve this problem internally in Wine in any sane way.

The current Windows directory and the current Windows directory
must be syncronized. BTW, is the "current" syncronization 
race free? (No, I haven't checked).

Reply via email to