»

[ChaosLord]

How do I check size and date of a file in ANSI C?

[Castellen]

I usually use stat() or lstat() though these might be more Unix specific???

More details in this thread.

[adolescent]

There's no function to get file date in pure ANSI C. But, look for stat() like Castellen mentioned.

[ChaosLord]

I am already using stat() but the problem is that stat() in SASC triggers a read of a nonexistent environment variable TZ which is lame and slow. I am doing thousands of stat() in a loop.

Accessing an environment variable for no reason every time you check the existence of a file sounds like something linux would do. So that is why I was searching for a cleaner way that is also multiplatform.

Does stat() in all compilers trigger this lame environment variable access? Or is it just some stupid thing in SASC? Its easy to run SnoopDos to check.

How can I do surgery on my SASC to amputate the offending code?

p.s. what the heck is the difference between stat() and lstat() ?

[chris]

Why not #ifndef around the block and add AmigaOS-specific replacement code?

You can use Lock() and Examine() or Open() and ExamineFH() to get a FileInfoBlock, which will tell you the date and size.

Chris

[ChaosLord]

@chris

The deal is that I could do your idea but
I would have to do it in many different places
and the code is already around 200,000 lines
and adding a bunch of giant blocks of #ifdef AMIGA
code would really messify things...

Do you know any secret trick to do it super elegantly and simply? :-)

[Karlos]

Why not simply write a wrapper function that does the job you need and simply have the implementation of that function #ifdef AMIGA ?

[Cymric]

ChaosLord wrote:
I am already using stat() but the problem is that stat() in SASC triggers a read of a nonexistent environment variable TZ which is lame and slow. I am doing thousands of stat() in a loop.

Either that, or change to a different c.lib, or use the #define-method, or write your own stat()-code which gets linked before c.lib. The last method is probably the best solution, as your portable fallthrough solution would be limited to one maintainable place in your code.

Accessing an environment variable for no reason every time you check the existence of a file sounds like something linux would do. So that is why I was searching for a cleaner way that is also multiplatform.

Since TZ is 'time zone', I am not at all impressed by this line of reasoning. That people do not use time zones and instead just force the clock of their computer to the right time is not SAS/C's fault---instead, it is following proper Unix programming guidelines.

p.s. what the heck is the difference between stat() and lstat() ?

On the Amiga, not really important, if memory serves me. The calls return different results when fed a file or a link, either hard or soft. One gives the results for the link itself, the other follows it through to the file pointed at. Links never worked properly under FFS. Or they did, but then only the softlink. Or was it the hardlink?

[ChaosLord]

Cymric wrote:

Either that, or change to a different c.lib, or use the #define-method, or write your own stat()-code which gets linked before c.lib. The last method is probably the best solution, as your portable fallthrough solution would be limited to one maintainable place in your code.

Okey dokey so I can make my own stat() function
that uses AmigaOS way of doing things that will fill in
a unix struct stat so all the time compare code will work without change.

BUT... how do I convert from AmigaDOS time format to Unix time_t format?

Since TZ is 'time zone', I am not at all impressed by this line of reasoning. That people do not use time zones and instead just force the clock of their computer to the right time is not SAS/C's fault---instead, it is following proper Unix programming guidelines.

But the timezone of my computer has nothing to do with the
time that some file was created many years ago on someone elses computer... Does it?

I guess you are saying that linux constantly converts all filedates to/from GMT?

So all filedates in linux are stored on the HD in GMT?

And since AmigaOS does not store filedates in GMT but
instead stores the actual date where it was created,
the stat() function in SASC should be rewritten
to NOT check TZ since adding in the user's TimeZone
under AmigaOS would then give the wrong date.

Correct?

[ChaosLord]

Karlos wrote:
Why not simply write a wrapper function that does the job you need and simply have the implementation of that function #ifdef AMIGA ?

Yes I was thinking the same thing :-)

But I donno how to convert from Amiga time to Unix time_t time. :-?

[Karlos]

Don't both systems measure time (32-bit integer) as the number of seconds since a particular epoch date?

If so, provided you know the difference between them. If memory serves, the Unix epoch is 00:00:00 Jan 01 1970 and the Amiga epoch is 00:00:00 Jan 01 1978

I would assume, if you evaluate the amiga epoch date as a unix datestamp you have a displacement you can use to convert an amiga 32-bit datestamp to a unix one and vice versa.