Board index » cppbuilder » utime woes - part 2

utime woes - part 2


2003-06-30 02:02:46 AM
cppbuilder48
Hello out there,
the issue is somewhat clearer now - but weird. Let me summarize:
- I am on Win98.
- I had a problem using utime.
- I took the code sample below (right from Builder's help on utime) -
but it didn't work either and gave the message:
Unable to set time of destination file: Invalid argument
- I stepped into utime. It's assembler, ok, but you can get its
sources from utime.c (_utime.c ?), so you can understand a bit what
happens.
- After a call to open it calls into _futime, so I step there, too.
- In _futime, some 20 or so instructions after the call to
_get_osfhandle there is a 'call -0x000001b6' - this being the first
call into 'unixtofile' (How do you know? You step into it and see it
reference _timezone like unixtofile does.)
Thanks for reading so far. Now for the weird part:
1) If I set a breakpoint at the beginning of _futime and then *just
continue* via F9 - the program works.
2) If I set a breakpoint at the first call into unixtofile *instead* -
it stops working.
So to me it looks like the program "needs some time" before calling
into unixtofile. If you just let it run up to this point (or not
setting a break point at all), something goes wrong. However, if you
stop a moment at the beginning of _futime, it works. Weird, isn't it?
Now this is probably dependent on the OS as well as the CPU and / or
CPU speed (here Win98 SE, AMD 1.33 GHz), and thus way beyond my
possibilities of debugging.
I'd welcome any comments.
This behaviour (running with a BP and not running if left alone)
strikes a memory of long ago:
At 8086 times we once needed to modify our own code at run-time (to be
able to construct addresses only available at run-time - don't ask
why). So we patched the code some addresses ahead of the current IP,
resulting in a 'call <wanted address>' instruction.
It worked - but only when stepping thru it with a de{*word*81}. Eventually
we found out why: The code 'ahead' containing the call was already in
the processor's pipeline, so we were only modifying it in memory
without the processor knowing anything about it. Remedy: Just add a
couple of NOPs (the pipeline was only six bytes long then), and it
worked like a charm. Pretty expensive NOPs though (in terms of time
spent).
Software developers sure live in interesting times ...
Best regards
Helmut Giese
BTW, I took the code from utime.c and built 'my_utime' from it - and
it doesn't produce this strange behaviour. This is, however, only a
partial solution, because in the original sources 2 functions are
called (_isDST and __NTerror) which I don't know how to duplicate.
------- code sample from Builder's help un _utime -------
/* Copies time stamp from one file to another */
#include <sys\stat.h>
#include <utime.h>
#include <stdio.h>
int main( int argc, char *argv[] )
{
struct stat src_stat;
struct utimbuf times;
if(argc != 3) {
printf( "Usage: utime <source file><dest file>\n" );
return 1;
}
if (stat(argv[1],&src_stat) != 0) {
perror("Unable to get status of source file");
return 1;
}
times.modtime = times.actime = src_stat.st_mtime;
if (utime(argv[2],×) != 0) {
perror("Unable to set time of destination file");
return 1;
}
printf ("Success\n");
return 0;
 
 

Re:utime woes - part 2

XXXX@XXXXX.COM (Helmut Giese) wrote:
This depends on exactly what your requirements are... If you want a
Windows solution, then use the Windows API:
(This from my FTP download function, but it works with regular
FindFirstFile.)
WIN32_FIND_DATA FindFrom;
ff = FtpFindFirstFile( hFTPSession, from, &FindFrom,
INTERNET_FLAG_RELOAD, NULL );
f=CreateFile(to,GENERIC_WRITE,0,NULL,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,NULL);
if( !SetFileTime( f, &FindFrom.ftLastWriteTime,
&FindFrom.ftLastWriteTime, &FindFrom.ftLastWriteTime ) )
{ some_error();
};
 

Re:utime woes - part 2

On Sun, 29 Jun 2003 13:37:04 -0700, Bob Gonder
< XXXX@XXXXX.COM >wrote:
Quote
XXXX@XXXXX.COM (Helmut Giese) wrote:

This depends on exactly what your requirements are... If you want a
Windows solution, then use the Windows API:
Hi Bob,
I appreciate your engagement, but there is some misunderstanding. The
example is just "cut-and-paste" from the help file to have *anything*
that uses utime. Apart from that I have no special interest in setting
one file's time stamp to that of another one.
What I am doing is porting a large, actively maintained open source
application (Tcl, in case you should ask) to also work when compiled
with Borland. It is maintained (for Windows) using VC++.
In this application there is code that calls utime, so I have to
provide for something which is named utime and behaves exactly like
utime (up to the errors it reports) - even if it is a home-brewn
version.
Sorry for the confusion
Helmut Giese
 

{smallsort}

Re:utime woes - part 2

XXXX@XXXXX.COM (Helmut Giese) wrote:
Quote
What I am doing is porting a large, actively maintained open source
application (Tcl, in case you should ask) to also work when compiled
with Borland. It is maintained (for Windows) using VC++.
In this application there is code that calls utime, so I have to
provide for something which is named utime and behaves exactly like
utime (up to the errors it reports) - even if it is a home-brewn
Ah, that could be tricky (the error part).