[jira] Closed: (AXIS2-3746) File setLastModified() in deployment code causes problems

["nadir amra (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/AXIS2-3746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

nadir amra closed AXIS2-3746.
-----------------------------

       Resolution: Fixed
    Fix Version/s: 1.4

Fixed.  Much cleaner and correct now. 

I will be putting this in the 1.4 release also. 

> File setLastModified() in deployment code causes problems
> ---------------------------------------------------------
>
>                 Key: AXIS2-3746
>                 URL: https://issues.apache.org/jira/browse/AXIS2-3746
>             Project: Axis 2.0 (Axis2)
>          Issue Type: Bug
>          Components: deployment
>            Reporter: nadir amra
>            Assignee: nadir amra
>            Priority: Critical
>             Fix For: 1.4, nightly
>
>
> I question the usage of the the File class's method setLastModified() in WSInfoList.java:
>     private void setLastModifiedDate(File file, WSInfo wsInfo) {
>         if (file.isDirectory()) {
>             File files [] = file.listFiles();
>             for (int i = 0; i < files.length; i++) {
>                 File fileItem = files[i];
>                 if (fileItem.isDirectory()) {
>                     setLastModifiedDate(fileItem, wsInfo);
>                 } else {
>                     fileItem.setLastModified(wsInfo.getLastModifiedDate());
>                 }
>             }
>         } else {
>             file.setLastModified(wsInfo.getLastModifiedDate());
>         }
>     }
> I do not understand why we are actually modifying the last-modified-date of the file objects?   
> The main reason is that this causes problems when the user ID that AXIS2 is running under does not have authority to update the files.  So the attempt to modify the files will not result on anything be done (we apparently do not check if operation failed), but more importantly, if system auditing is enabled you will see authority-failure auditing records for each attempt to modify the time-stamp for a file.  And if hot-update is deployed, this will result in 1000's of these records.  
> Possible solution:  Why do we need to test for equality when looking at time-stamps? We can save the newest last-modified time-stamp, and then when we want to detect if something has changed, we simply see if the saved time-stamp is greater or equal to the file time-stamp.  And if this is true, then the file has not changed.  Otherwise, the file has changed.....the added benefit is we do not have to update files. 
> I will be fixing this ASAP and hopefully will be getting this into Axis 1.4.  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org