Hi, Jerry Coffin!
On 03 Sep 97  01:56:28 you wrote to Balog Pal
 BP> I just ran into a problem. Is there something in WIN32 like the
 BP> ctirical section in DOS was?
 JC> Not really.  I'm assuming you mean the function that keeps DOSSHELL
 JC> and/or Windows 3.x from switching to another task?
Yes.
 BP> But isn't there a simpler method to prevent a task switch for a short
 BP> section in the program?  I have a program that is polling directories
 BP> and moves the files that apper there to another directories.  Another
 BP> program creates those files. In several places it simply uses
 BP> MoveFileEx itself.
 JC> That shouldn't be a problem.  If one process attempts to use
 JC> MoveFileEx (or MoveFile) on a file while another process has the file
 JC> open, the attempt at moving the file will fail.
But I fear the opposite situation. I move files to a directory that is polled
for files that appears there. I use MoveFileEx with COPY_ALLOWED as they may
be on another volume.
 BP> I found it works in practice. Bus thinking a bit deeper I consider
 BP> it's not really safe that way. What if a task switch occours when the
 BP> system is in the middle of MoveFileEx?
 JC> The OS ensures that moving the file takes place atomically, or at
 JC> least appears to do so.
That I'm not really sure. The simple rename/move is atomical. But if the
system use copy and delete it may not be, at least I found no dox on that.
(And I assume such copying a very long file will unlikely hold up the whole
system by deault.)
 JC> However, you might want to take a look at FindFirstChangeNotification
Good Idea. ... Well, it's cute but not really for me. Under normal
circumstances the dir is empty and if FindFirst finds something there it
should be processed promptly.
 JC> or (better yet) ReadDirectoryChangesW to take care of things even more
 JC> simply.
Hm, this I could not find in help of VC 4.0.  I will check it in 5.0 too, but
I have to reboot to NT 4 to do that. :(
 JC> It's not entirely clear what you're doing, but from the sound
 JC> of things ReadDirectoryChangesW might be your best bet if you can
 JC> limit your program to NT.
Hm, that's not likely, most of those proggies I must time-to time port to
Solaris. We have a real messy system with mozaic of nearly a dozen proggies
that pass messages to each other wia DDE, files, X.400 mail, TCP/IP, and some
of them are on a Sun, some on NT. And many have alteregos on the opposite
system.   [That certainly doesn't mean I will not use any opsys-specific
stuff, but I must consider promptly that how will I port that.]
 JC> (Even more than many of the OS/2 and UNIX
 JC> fans, I can hardly wait for the day Win95 is dead and buried.
Yeah. I aws lucky enough to miss that system completely [kopp-kopp-kopp:] as
all out clients switched directly to NT from win31 or to other systems. W95
is probably just for home play, but today's hardware prices make even that
questionable. Unfortunately MS seems to bribe a plenty of PC game-factories
to write games to work only on W95 (no dos, no NT4). That makes it more
resistant to time. :-((
Paul
... Abandon all hope, ye who PRESS ENTER here
--- OS/2 Warp
---------------