waiting period

[Hans Vlems]

Problem description: the program modifies files and the filesystem is
somewhat slow.
More specifically, two subsequent calls on the rename function for one
file fail because the filesystem is slowed down for reasons unknown.
Waiting for one second is sufficient to avoid this effect. My somewhat
crude workaround is a wait function that implements a busy form of
waiting:

starttime=time(NULL);
while (difftime(time(NULL),starttime)<2) // wait 2 seconds
{
... calculates sin() and pow() many times
}

Is there a more elegant way to suspend a program for specific period
of time (accuracy: seconds) ?

The compiler in use is GCC 4.4.4 for Windows (the djgpp distribution
that runs in command line mode).
Hans

 

[David Resnick]

Problem description: the program modifies files and the filesystem is
somewhat slow.
More specifically, two subsequent calls on the rename function for one
file fail because the filesystem is slowed down for reasons unknown.
Waiting for one second is sufficient to avoid this effect. My somewhat
crude workaround is a wait function that implements a busy form of
waiting:

 starttime=time(NULL);
 while (difftime(time(NULL),starttime)<2)   // wait 2 seconds
 {
    ... calculates sin() and pow() many times
 }

Is there a more elegant way to suspend a program for specific period
of time (accuracy: seconds) ?

The compiler in use is GCC 4.4.4 for Windows (the djgpp distribution
that runs in command line mode).
Hans

There is no portable way other than a busy loop. But nobody
recommends busy loops.
Here: http://c-faq.com/osdep/subsecond.html are listed some of the OS
dependent ways to do it...

-David

 

[Angel]

Is there a more elegant way to suspend a program for specific period
of time (accuracy: seconds) ?

The compiler in use is GCC 4.4.4 for Windows (the djgpp distribution
that runs in command line mode).
Hans

On POSIX-compliant systems you can use sleep(). Don't know if the above
setup is POSIX-compliant though, I only work with Linux.

 

[Hans Vlems]

On POSIX-compliant systems you can use sleep(). Don't know if the above
setup is POSIX-compliant though, I only work with Linux.

Thanks, I found a reference to sleep() in unistd.h!
Hans

 

[robertwessel2]

Problem description: the program modifies files and the filesystem is
somewhat slow.
More specifically, two subsequent calls on the rename function for one
file fail because the filesystem is slowed down for reasons unknown.
Waiting for one second is sufficient to avoid this effect. My somewhat
crude workaround is a wait function that implements a busy form of
waiting:

 starttime=time(NULL);
 while (difftime(time(NULL),starttime)<2)   // wait 2 seconds
 {
    ... calculates sin() and pow() many times
 }

Is there a more elegant way to suspend a program for specific period
of time (accuracy: seconds) ?

The compiler in use is GCC 4.4.4 for Windows (the djgpp distribution
that runs in command line mode).
Hans

While other folks have commented on your actual question, you have a
different issue here. There really aren't any issues like you
describe in Window, and it's certainly hard to imagine ones that would
be "fixed" with a wait of a second or two. It's more likely you're
hitting some race condition in your application (are you using
asynchronous I/O or threads to do the mods?) or in the DJGPP mapping
layer (although that's somewhat less likely).

Whatever it is, patching around what is almost certainly a problem in
your application is a really bad idea, and might very well come back
to haunt you if you run on a different machine that alters the timing
enough to generate the problem again).

 

[Seebs]

Problem description: the program modifies files and the filesystem is
somewhat slow.

More specifically, two subsequent calls on the rename function for one
file fail because the filesystem is slowed down for reasons unknown.

Stop!

Find out what is actually happening here. Otherwise, all that will happen
is you'll have more erratic behavior later -- say, you'll have something
that blows up in the afternoons, or only during peak Netflix streaming
hours, or on Fridays in Lent.

It is fine to work around a problem *once you know what it is*. You should
never let "reasons unknown" fester in your project.

Waiting for one second is sufficient to avoid this effect. My somewhat
crude workaround is a wait function that implements a busy form of
waiting:

Don't do that. The solution depends on your host environment, but I don't
think there's anything out there on which there isn't a better solution.

Is there a more elegant way to suspend a program for specific period
of time (accuracy: seconds) ?
Yes.

The compiler in use is GCC 4.4.4 for Windows (the djgpp distribution
that runs in command line mode).

You might try a Windows group, or see whether it has a sleep() function,
since I seem to recall that one of the popular gcc-for-Windows distributions
includes some Unixy stuff.

-s

 

[Michael Mouse]

DJGPP is for DOS and that may be the problem, running a DOS program
under NT based Windows.

 

[copx]

"Michael Mouse" wrote in message

DJGPP is for DOS and that may be the problem, running a DOS program
under NT based Windows.

Indeed. DJGPP is a DOS compiler. The current version of Windows (Windows 7)
may execute this or that DOS app, but it probably won't work correctly.
DJGPP is only stable on DOS and to a lesser extend on Windows 9x.

 

[Eric Sosman]

in message


Indeed. DJGPP is a DOS compiler. The current version of Windows (Windows 7)
may execute this or that DOS app, but it probably won't work correctly.
DJGPP is only stable on DOS and to a lesser extend on Windows 9x.

(Shrug.) Works fine for me on XP. Then again, I'm not trying
to rename() the same file forty-leven times in three milliquivers,
either. YMMV.

 

[Kenny McCormack]

(Shrug.) Works fine for me on XP.

The implication seems to be that in Vista/Windows7/whatever, they (MS)
are going to actually remove DOS support. There are political reasons
why some people like to push this as an agenda, but I doubt it will ever
really happen.

Then again, I'm not trying
to rename() the same file forty-leven times in three milliquivers,
either. YMMV.

heh heh. Good one.

--
Religion is regarded by the common people as true,
by the wise as foolish,
and by the rulers as useful.

(Seneca the Younger, 65 AD)

 

[robertwessel2]

The implication seems to be that in Vista/Windows7/whatever, they (MS)
are going to actually remove DOS support.  There are political reasons
why some people like to push this as an agenda, but I doubt it will ever
really happen.

Native support for 16 bit apps, both DOS and Win16, has been removed
from all 64 bit versions of Windows (this is true for 64 bit versions
of XP, Vista and Win7, as well as the Server equivalents), but remains
in all 32 bit versions (actually being implemented via an emulator on
non-x86 versions of Windows). The partial/public justification is
that 64-bit mode on x86 drops support for virtual-86 mode, but the
major real reason is that Windows applications can all interact with
each other via messages and other mechanisms, and the need to support
16 bit handles and whatnot introduces excessively burden on the rest
of the system, or requires an excessively complex mapping layer. That
and clearly MS wants to stop dealing with all the Win16 compatibility
issues.

In any event, MS uses their VM technology with Win7 to provide a
canned 32 bit WinXP VM (cleverly called "XP Mode"), where you *can*
run 16 bit apps (as well as 32 bit apps that have compatibility issues
with later versions). Unfortunately not all versions of Win7 are
licensed to use XP Mode (or at least that was true in the past, I've
not looked at the terms for the basic versions lately). On the Server
versions, while MS doesn't supply a neatly packaged XP Mode, they do
provide their VM product, and the licenses typically allow you to run
at least one guest for compatibility purposes (but you're mostly stuck
installing that guest OS yourself).

And you can use DOSBox (obvious URL) to run many DOS applications
(including many games) on Win64 (not to mention many non-x86 and non-
Windows ssytems). Even many programs that have issues under the
native DOS emulation in the 32 bit versions of Windows. And there are
other VM products you can use, of course.

 

[Paul N]

Problem description: the program modifies files and the filesystem is
somewhat slow.
More specifically, two subsequent calls on the rename function for one
file fail because the filesystem is slowed down for reasons unknown.
Waiting for one second is sufficient to avoid this effect.

Just to throw one possibility into the mix...

Windows apparently has a feature called "file tunneling", described
for example at http://support.microsoft.com/default.aspx?scid=kb;en-us;172190
.. This means that if you do things to a file in quick succession the
results are not what you might expect.

I don't know if this is anything to do with what you are suffering,
but since you are getting odd results when you do things to a file in
quick succession, and don't when you don't, it seems worth mentioning.

I'm not at all an expert on it, but maybe other people here are.

 

[Hans Vlems]

     (Shrug.)  Works fine for me on XP.  Then again, I'm not trying
to rename() the same file forty-leven times in three milliquivers,
either.  YMMV.

In this case djgpp runs on a 64 bit Windows Server platform. It runs
fine, no issues at all.
All files I needed are there and, as said, sleep() is available.
The program does not touch the contents of the file, it just renames
the file according to a given specification.
Under certain conditions two subsequent calls to rename() for the same
file may happen. It happened once that a stray
copy of the file remained on disk. Both the real and the stray file
had the same content and that content was correct.
I ran the program on Tru64 and VMS (on an ODS-5 disk) and the program
ran without a problem. So I tend to agree with another poster that I
ran into a race problem, and a pretty rare one as well.
Hans

 

[Mickey Mouse]

On Wed, 26 Jan 2011 14:18:37 -0800 (PST), Hans Vlems

Hans

Is there a particular reason to use DJGPP rather than MinGW?

 

[Hans Vlems]

On Wed, 26 Jan 2011 14:18:37 -0800 (PST), Hans Vlems


Hans

Is there a particular reason to use DJGPP rather than MinGW?

No particular reason other than that I wanted a C compiler that runs
from the command line.
minGW has no support for posix, which means (I think) that it doesn't
support unistd.h and I need that.
Furthermore I don't want to design windows programs, the software runs
from the commandline.

The environment is Windows Server and Citrix, so as an ordinary user I
cannot install software that modifies the registry.
Installing DJGPP is as simple as unzipping a file.
Programming wasn't part of the project in the first place. But it
would be nice if we had this functionality so I decided to write a
program for it. Documents are scanned and the pdf file ends up in a
directory. Each file is inspected and when it passes the quality check
it is moved manually to another directory. The target directory
structure consists of > 1000 directories, each with 14 subdirectories
and a file resides in one of these. The rules for moveing a file are
simple but for humans the operation is error prone. Hence the need for
a program.
The filenames follow a standard and the standard specifies uppercase
codes.
The reason for two subsequent renames is that NTFS is not case
sensitive but only preserves case. On a unix system, abc and ABC are
two different files. NTFS creates a file with the name abc or with the
name ABC but not both.
So calling rename("abc","ABC") will work on unix but won't on WIndows
Server.
Hans

 

[Mickey Mouse]

No particular reason other than that I wanted a C compiler that runs
from the command line.

Mingw does that.

minGW has no support for posix, which means (I think) that it doesn't
support unistd.h and I need that.

Mingw has unistd.h for compatability purposes but all the file
handling function are in io.h and stdio.h. DJGPP is only partially
POSIX complient, less sop than Windows and Windows is not fully
complient (no sockets and threads).

Furthermore I don't want to design windows programs, the software runs
from the commandline.

These are consul programs that are actualy windows programs that use a
text based window. (Like ping, format do and DJGPP programs)

The environment is Windows Server and Citrix, so as an ordinary user I
cannot install software that modifies the registry.

Mingw does require that the environment be modified so that PATH
includes the Mingw bin directory. I would thing that a user can change
the users enironment. On searching my registry the only instance of
"Mingw" in the registry is for my user names environment for PATH, if
that is a problem then MSYS will get around that for you.

Installing DJGPP is as simple as unzipping a file.

Mingw does have an installer that is more like a downloader unzipper
than an installer.

So calling rename("abc","ABC") will work on unix but won't on WIndows
Server.

It does on XP and does on Win2K server, the case changes.

#include <stdio.h>
#include <stdlib.h>

int main (void)
{
FILE *f;

f = fopen ("abc", "wt");
fclose(f);
rename("abc","ABC");
return 0;
}

 

[Kenny McCormack]

It does on XP and does on Win2K server, the case changes.

Daffy Duck says: That's not the point!

--
One of the best lines I've heard lately:

Obama could cure cancer tomorrow, and the Republicans would be
complaining that he had ruined the pharmaceutical business.

(Heard on Stephanie Miller = but the sad thing is that there is an awful lot
of direct truth in it. We've constructed an economy in which eliminating
cancer would be a horrible disaster. There are many other such examples.)

 

[Hans Vlems]

Mingw does that.


Mingw has unistd.h for compatability purposes but all the file
handling function are in io.h and stdio.h.  DJGPP is only partially
POSIX complient, less sop than Windows and Windows is not fully
complient (no sockets and threads).


These are consul programs that are actualy windows programs that use a
text based window. (Like ping, format do and DJGPP programs)


Mingw does require that the environment be modified so that PATH
includes the Mingw bin directory. I would thing that a user can change
the users enironment.  On searching my registry the only instance of
"Mingw" in the registry is for my user names environment for PATH, if
that is a problem then MSYS will get around that for you.


Mingw does have an installer that is more like a downloader unzipper
than an installer.


It does on XP and does on Win2K server, the case changes.

#include <stdio.h>
#include <stdlib.h>

int main (void)
{
  FILE *f;

  f = fopen ("abc", "wt");
  fclose(f);
  rename("abc","ABC");
  return 0;



}- Tekst uit oorspronkelijk bericht niet weergeven -

- Tekst uit oorspronkelijk bericht weergeven -

When I started on this program all we needed was very basic
functionality and version 1.0
was less than 100 lines of code. So any gcc compiler was fine, as long
as it was useful without
installing it in the registry (no access, this lives outside ICT
scope).
Four weeks later I sit on >3000 lines of code... And I find DJGPP very
reliable indeed. No worries.

The fact that it works on XP et al, well that's Windows I guess.
Pretty stable these days but sometimes unpredictable.
As said, on Tru64 the program runs just fine without the cumbersome
second rename().
Which is a kludge in my opinion, no need to convince me there.
Given the difference in behaviour among the various Windows platforms
and the fact that
the problem with the stray copy happened just once I feel I can live
with this for a couple
of months. I just ran the program on todays production files and the
"intermediate" filenames show up in the explorer.
I wrote a program that checks whether the files ended up where they
should and no errors, neither do I expect them.

So, yes, minGW might have been a better choice. But DJGPP produces
fine code and I really don't want to change tools.
Thanks for your research on rename, I really appreciated that!
Hans