Problem with File on CD/DVD

Windows
1

a friend of mine have to categorize some image cds he got (hundreds) so i’ve done a little database browser/creator for his data.
after some trying i’ve found that doing (shortly):

File file ("D:\\something.xxx");
String time = file.getLastAccessTime().formatted ("some format");

where D: being a CD or DVD drive, i reach an assert:

File: loctim64.c
Line: 78
Expression: (*ptime <= _MAX__TIME64_T)

<callstack>
 	tridir.exe!_crt_debugger_hook(int _Reserved=18742100)  Line 62	C
 	tridir.exe!_invalid_parameter(const wchar_t * pszExpression=0x0076a8c0, const wchar_t * pszFunction=0x0076a92c, const wchar_t * pszFile=0x0076a950, unsigned int nLine=78, unsigned int pReserved=0)  Line 86 + 0x7 bytes	C++
 	tridir.exe!_localtime64_s(tm * ptm=0x011df914, const __int64 * ptime=0x011df7ec)  Line 78 + 0x7f bytes	C
 	tridir.exe!localtime_s(tm * _Tm=0x011df914, const __int64 * _Time=0x011df7ec)  Line 123 + 0xd bytes	C++
 	tridir.exe!juce::millisToLocal(const __int64 millis=1833029933770955, tm & result={...})  Line 70 + 0xd bytes	C++
>	tridir.exe!juce::Time::formatted(const wchar_t * const format=0x00755ee8)  Line 300 + 0x16 bytes	C++
...

cause millisSinceEpoch in Time class doesn’t seem a valid. or at least i don’t know what the hell is going on.

const String Time::formatted (const tchar* const format) const
{
    tchar buffer[80];

    struct tm t;
    millisToLocal (millisSinceEpoch, t); // breaking here

and this with all the files and all the CD/DVD i insert into the case.
with local (variuos HD, sata usb and ide) or network paths (directly “\server” or mapped through a drive letter) it works seamlessly.

just to notice, why this shouldn’t work i don’t know, mikro$oft should pay for this…

2

Hmm. Not sure what I could do about that, it just seems like the numbers are nonsense, but they’re all coming from win32 code.

If you do a release build do you still get the assertion? It doesn’t seem like there’d be any actual damage caused by this, because it’d just return a null time.

3

in release mode it just throw a memory access error and the application get killed abruptly. maybe in the Time class there could be some check for non-sense numbers, to avoid a breakage like this ? for the app i can avoid using last access in this case… but i was just reporting this, not a real pain: the interesting thing is that the memory access error comes from winBLOWS libraries… not yours ! jules 100 - microflop 0 ehehe

4

Ok, well this seems to do the trick of avoiding out-of-range numbers:

[code]static void millisToLocal (const int64 millis, struct tm& result) throw()
{
time_t now = (time_t) (millis / 1000);

#ifdef JUCE_WIN32
#ifdef USE_NEW_SECURE_TIME_FNS
if (now >= 0 && now <= 0x793406fff)
localtime_s (&result, &now);
else
zeromem (&result, sizeof (result));
#else[/code]

Can’t understand why the filesystem would be returning rubbish like that in the first place, though…