Filtering Time With FindFile

Question

0.00/5 (No votes)

See more:

Ok, I have this code that is giving me the number of files in a directory and it's working just skippy. The problem I now have and I'm hopeing it's my last one is that I want only the files that are less than a minute old. Just how do I add that filter to this code? Any suggestions are welcome. Thank you so very much everyone.

C++

struct file_data 
{ 
    std::wstring sLastAccessTime; 
    __int64 nFileSize      ; 
}; 
 
int GetFileList(const wchar_t *searchkey, std::map &map) 
{ 
    WIN32_FIND_DATA fd; 
    HANDLE h = FindFirstFile(searchkey,&fd); 
    if(h == INVALID_HANDLE_VALUE) 
    { 
        return 0; // no files found 
    } 
    while(1) 
    { 
        wchar_t buf[128]; 
        FILETIME ft = fd.ftLastWriteTime; 
        SYSTEMTIME sysTime; 
        FileTimeToSystemTime(&ft, &sysTime); 
        wsprintf(buf, L"%d-%02d-%02d",sysTime.wYear, sysTime.wMonth, sysTime.wDay); 
 
        file_data filedata; 
        filedata.sLastAccessTime= buf; 
        filedata.nFileSize      = (((__int64)fd.nFileSizeHigh) << 32) + fd.nFileSizeLow; 
 
        map[fd.cFileName]= filedata; 
 
        if (FindNextFile(h, &fd) == FALSE) 
            break; 
    } 
    return map.size(); 
}

Posted 29-Sep-11 17:40pm

Member 7766180

Add a Solution

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Chuck O'Toole · Answer 1 · 2011-09-29T18:11:00

Solution 1

Come on dude, your code has

FILETIME ft = fd.ftLastWriteTime;
SYSTEMTIME sysTime;
FileTimeToSystemTime(&ft, &sysTime);

already and you're asking where to put time checks?

Google / Bing / Yahoo Search for SYSTEMTIME, FILETIME and you'll find tons of articles on how to do arithmetic on those values. Hint,

C#

#define ONEDAY    ((__int64)(__int64)10000000*(__int64)(60*60*24))
#define ONEHOUR   ((__int64)(__int64)10000000*(__int64)(60*60))
#define ONEMINUTE ((__int64)(__int64)10000000*(__int64)(60))

will help you with the math and what the units are from your research into how files record times.

Posted 29-Sep-11 18:11pm

Chuck O'Toole

Comments

Member 7766180 30-Sep-11 0:34am

Ok thats fair. I'm off and running! Thank you.

Sergey Alexandrovich Kryukov 30-Sep-11 1:11am

Here we go. My 5.
--SA

Chuck O'Toole 30-Sep-11 1:42am

thanks. And yes, here we go again.

Member 7766180 30-Sep-11 1:36am

Ok SA and Chuck. Would I subtract 60 * 1000 * 10000LL from FILETIME?
FileTimeToSystemTime(&ft-60 * 1000 * 10000LL, &sysTime);

Chuck O'Toole 30-Sep-11 1:40am

imprecise question. FILETIME is a data type, you might as well ask "should I subtract .... from 'int'. What 'data item' do you want to subtract from? And if you do identify what you want to subtract from, what do you think that will give you?

Member 7766180 30-Sep-11 1:42am

Look Up.

Chuck O'Toole 30-Sep-11 1:47am

Looked. Saw your edit, still do not see the answer to my question "And if you do identify what you want to subtract from, what do you think that will give you?" Answer that, subtracting that number from 'ft' will accomplish WHAT? You tell me. I could tell you but then you won't learn nothing.

Member 7766180 30-Sep-11 1:52am

I thought that &ft represented the actual filetime so I figured filetime - 60 * 1000 * 10000ll would give me the filetime minus 0ne minute. Also I found this, which kind of matches the size code.
FILETIME ft;
__int64 time = ((__int64)ft.dwHighDateTime << 32) + ft.dwLowDateTime;

Chuck O'Toole 30-Sep-11 2:08am

Yes, you are correct, that will tell you the time one minute before the file was written, which has nothing at all to do with the age of the file. For example, if 'ft' translates to 11-Jan-2009:10:14:54.33, what good does 11-Jan-2009:10:13:54.33 do you? Yes, it's one minute before the file was written but is that what you want?

Member 7766180 30-Sep-11 2:21am

It does me no good. meaningless! FILETIME needs to be changed to SYSTEMTIME, then the actual files need to be compared to that conversion and if they are one minute or less then they pass.
From Uncle Bill.

It is not recommended that you add and subtract values from the FILETIME structure to obtain relative times. Instead, you should copy the low- and high-order parts of the file time to a ULARGE_INTEGER structure, perform 64-bit arithmetic on the QuadPart member, and copy the LowPart and HighPart members into the FILETIME structure.

Chuck O'Toole 30-Sep-11 2:33am

Congratulations! 100% precise answer. You have earned a big hint: you want the system time changed to filetime, try GetSystemTimeAsFileTime(). All set to do your math.

Member 7766180 30-Sep-11 2:35am

Look Up, Just found, should I worry?

Chuck O'Toole 30-Sep-11 2:41am

I have no idea why they tell you that unless they are worried about the sign. I typecast them to __int64 all the time, been doing it for years.

Member 7766180 30-Sep-11 2:42am

Ok, I have this........
FILETIME ftNow;
GetSystemTimeAsFileTime(&ftNow);
auto ftAs64 = ftOneMinuteAgo.dwLowDateTime + ((unsigned __int64)ftOneMinuteAgo.dwHighDateTime << 32) - 6000000000UL;
FILETIME ftOneMinuteAgo = { (DWORD)ftAs64, (DWORD)(ftAs64 >> 32) }; Is this a start? Do I need more? Thanks, Chuck!