none
How to get last file modified date time of a remote file

    Question

  • Hi All,

    I am a newbie of FTP. I am using VC6 in XP.  I want to download a file from FTP server. And set the
    file date time equals the one in the server. But I cannot get the correct
    file status of remote file. It return zero in file status.

    Please help.
    BR

    Below is my code :

    CInternetFile *pInetFile=NULL;

    CFileStatus   FileStatus;

    pSession = new CInternetSession();

    try
    {    pFTP = pSession->GetFtpConnection("ftp_web_site",
            "username","password",INTERNET_INVALID_PORT_NUMBER);

    }

    catch(CInternetException *pEx)

    {    pEx->ReportError(MB_ICONEXCLAMATION);    pFTP = NULL;
         pEx->Delete();    return;

    }

    // download file

    m_pFtpConnection->GetFile("myfile", cLocalPathname,
        TRUE,FILE_ATTRIBUTE_NORMAL,FTP_TRANSFER_TYPE_BINARY,1);

    pInetFile = pFTP->OpenFile("myfile");

    pInetFile->GetStatus(FileStatus);   // <= error in file status, all zero

    Thursday, August 26, 2010 1:53 AM

Answers

  • OK, thanks for confirming that.  I notice that GetStatus() is a member of CFile rather than the CInternetFile class, which derives from CFile.

    I also notice that CFtpConnection::OpenFile says:

    After calling OpenFile and until calling CInternetConnection::Close, the application can only call CInternetFile::Read, CInternetFile::Write, CInternetConnection::Close, or CFtpFileFind::FindFile. Calls to other FTP functions for the same FTP session will fail and set the error code to FTP_ETRANSFER_IN_PROGRESS.

    CFile::GetStatus() is not an FTP function, but you are trying to use it as one (you want the status of the remote file).  I suspect that what's happening is that the CFile data in the object is being treated as the local version of the file, which (because you have not yet read anything from the remote file) is empty and therefore has zero length.

    Perhaps what you really need is the CFtpFileFind class together with its CFileFind::GetLength base member.


    Answering policy: see profile.
    Tuesday, August 31, 2010 9:10 PM
  • A file read is added.  Then, nBytesRead =1024 and bRet=1 and fs=0 (m_mtime, m_ctime and m_atime =0)

    I think it should return a FALSE (pInetFile->GetStatus(fs )).

     Possibly, but to be honest I think you may be asking too much of it.

    From other document (http://social.msdn.microsoft.com/forums/en-us/netfxnetcom/thread/20629336-3894-435C-9D90-07A09CAD2B57), the file date can be obtained by parsing the response string.

    I still think you should at least try CFtpFileFind::FindFile followed by CFtpFileFind::FindNextFile, then call the CFileFind::GetLastWriteTime method before going down this route.  Note that the behaviour of CFileFind is slightly odd - you need to call the FindNextFile before you can get at the attributes of the first file found.
    Answering policy: see profile.
    Wednesday, September 01, 2010 11:19 AM

All replies

  • That cannot be all of the relevant code; m_pFtpConnection has no apparent relationship to pFTP.  Failing to post all relevant code means that we have to guess what's going on, making it less likely you will get a good answer.

    In any situation like this, my first advice is CHECK THE RETURN STATUS of every call before relying on the result (and before posting a question about it :). 

    In this case, you don't know whether any of the calls to GetFile(), OpenFile() or GetStatus() succeeded or failed, so there could be any number of reasons for the unexpected file status value.

    Please address these issues first, and if the problem persists then post all the relevant code, and giving any error information.

    (If, contrary to what you have posted, your actual code does check these return values and you have merely omitted them from the posted code, then I apologise!)


    Answering policy: see profile.
    Thursday, August 26, 2010 10:34 AM
  • Hi,

    Below is the latest source code , pInetFile->GetStatus(fs); It return zero in file status.

    Please help.
    BR

     

    CInternetSession    Session;

    CFtpConnection      *pFTP;

    CInternetFile       *pInetFile=NULL;

    CFileStatus         fs;

    BOOL bRet =TRUE;

     

    CString cLocalFile = "C:\\myfile";

    CString cRemoteFile = "myfile";

     

    try

    {

    pFTP = Session.GetFtpConnection(“mysite”,”myusername”, “mypassword”   , INTERNET_INVALID_PORT_NUMBER);

      }

      catch(CInternetException *pEx)

      {

         pEx->ReportError(MB_ICONEXCLAMATION);

         pFTP = NULL;

         pEx->Delete();

         bRet=FALSE;

    }

    if (bRet==FALSE)     

              return bRet;

     

    // download a file

    BOOL bRet2 = pFTP->GetFile(cRemoteFile, cLocalFile,

    FALSE, FILE_ATTRIBUTE_NORMAL,FTP_TRANSFER_TYPE_BINARY,1);

     

    if (bRet2==FALSE)

    {

    MessageBox("Error in download file "); return FALSE;

    }

     

    // get remote file status

    pInetFile = pFTP->OpenFile(cRemoteFile);

    if (pInetFile)

    pInetFile->GetStatus(fs);

    pInetFile->Close();

     

    pFTP->Close();

    pFTP=NULL;

    Session.Close();


    Friday, August 27, 2010 3:22 AM
  • You still have not checked the return status of pInetFile->GetStatus(fs);


    Answering policy: see profile.
    Monday, August 30, 2010 5:29 PM
  •  

    It return TRUE in statement pInetFile->GetStatus(fs);

    BR


    Tuesday, August 31, 2010 1:27 AM
  • OK, thanks for confirming that.  I notice that GetStatus() is a member of CFile rather than the CInternetFile class, which derives from CFile.

    I also notice that CFtpConnection::OpenFile says:

    After calling OpenFile and until calling CInternetConnection::Close, the application can only call CInternetFile::Read, CInternetFile::Write, CInternetConnection::Close, or CFtpFileFind::FindFile. Calls to other FTP functions for the same FTP session will fail and set the error code to FTP_ETRANSFER_IN_PROGRESS.

    CFile::GetStatus() is not an FTP function, but you are trying to use it as one (you want the status of the remote file).  I suspect that what's happening is that the CFile data in the object is being treated as the local version of the file, which (because you have not yet read anything from the remote file) is empty and therefore has zero length.

    Perhaps what you really need is the CFtpFileFind class together with its CFileFind::GetLength base member.


    Answering policy: see profile.
    Tuesday, August 31, 2010 9:10 PM
  •  

    Thanks for your answer !

    I have modified the code as follows :

      CFileStatus         fs;

        pInetFile = pFTP->OpenFile(cRemoteFile );
        if (pInetFile)
        {
            char buf[1024];
            UINT nBytesRead  = pInetFile->Read(buf, 1024);
            bRet = pInetFile->GetStatus(fs );

        }
        pInetFile->Close();

    A file read is added.  Then, nBytesRead =1024 and bRet=1 and fs=0 (m_mtime, m_ctime and m_atime =0)

    I think it should return a FALSE (pInetFile->GetStatus(fs )).

    From other document (http://social.msdn.microsoft.com/forums/en-us/netfxnetcom/thread/20629336-3894-435C-9D90-07A09CAD2B57), the file date can be obtained by parsing the response string.

     

     

     

     

     

    Wednesday, September 01, 2010 1:23 AM
  • A file read is added.  Then, nBytesRead =1024 and bRet=1 and fs=0 (m_mtime, m_ctime and m_atime =0)

    I think it should return a FALSE (pInetFile->GetStatus(fs )).

     Possibly, but to be honest I think you may be asking too much of it.

    From other document (http://social.msdn.microsoft.com/forums/en-us/netfxnetcom/thread/20629336-3894-435C-9D90-07A09CAD2B57), the file date can be obtained by parsing the response string.

    I still think you should at least try CFtpFileFind::FindFile followed by CFtpFileFind::FindNextFile, then call the CFileFind::GetLastWriteTime method before going down this route.  Note that the behaviour of CFileFind is slightly odd - you need to call the FindNextFile before you can get at the attributes of the first file found.
    Answering policy: see profile.
    Wednesday, September 01, 2010 11:19 AM