| Title: | Kit: Note 4229; Please use NOTED::PWDOSWIN5 for V4.x server | 
| Notice: | Kit: Note 4229; Please use NOTED::PWDOSWIN5 for V4.x server | 
| Moderator: | CPEEDY::KENNEDY | 
| Created: | Fri Dec 18 1992 | 
| Last Modified: | Fri Jun 06 1997 | 
| Last Successful Update: | Fri Jun 06 1997 | 
| Number of topics: | 4319 | 
| Total number of notes: | 18478 | 
    I have a customer having intermitten problem of seeing file dates
    changed when she copied files from the network drive one folder to
    another folder in the same network drive.
    
    She has seen this on PATHWORKS 4.1/WIN311 clients and NT4.0 - SP2
    client.  Our server is PW50D-ECO3.  I have observed this happen on her
    machine, but have no luck recreating the problem easily.  Is there an
    explanation to this?
    
    Having long discussion with the CSC support,  one possible solution is
    to provide a FAT volume for her.  With no explanation to this problem
    and no easy way to reproduct the problem, I am not sure whether it is
    an overkill to her problem.  I was hoping an explanation first, discuss
    it with this customer second, then if needs to go for whatever the fix
    needed for the date problem.
    
    
    Thanks,
    Yuh-Juan 
| T.R | Title | User | Personal Name | Date | Lines | 
|---|---|---|---|---|---|
| 4266.1 | UTRTSC::SWEEP | I want a lolly... | Mon Apr 21 1997 05:55 | 7 | |
|     A created file gets entered in the cache. Only when the
    file is actually closed, the file header is updated.
    
    Are you seeing this maybe ?? We have the OFC which can
    hold off any closures.
    
    Adrie
 | |||||
| 4266.2 | Thanks, what is OFC? | JULIET::HUNG_YU | Yuh-Juan Hung@WRO | Tue Apr 22 1997 00:22 | 25 | 
| >    A created file gets entered in the cache. Only when the
>    file is actually closed, the file header is updated.
    
    We've noticed sometimes during the copy, the file dates are changed for
    a short period and after the copy is completed, the dates are switched
    back to the original.  This could be what you are saying the cache that
    we are seeing at the destination location that sometimes shows the dates
    changed and then updated to the original dates after the copy is done?
    
>    Are you seeing this maybe ?? We have the OFC which can
>    hold off any closures.
    
    The one that I observed a group of files copied and dates changed and
    stayed changed for at least 10-15 minutes when I was there.  The dates
    never changed back.  Something happened to these files??
    
    What is OFC?  Sorry please explain.  
    
    
    Thanks a lot,
    Yuh-Juan
    
    
    
    
 | |||||
| 4266.3 | UTRTSC::SWEEP | I want a lolly... | Tue Apr 22 1997 03:48 | 11 | |
|     OFC = Open File Cache.
    
    When a file close request is issued, the file not NOT
    closed immediately but delayed for OFC_INTERVAL (5 sec's).
    
    If within that timeframe the file is opened again (by the
    same PC) then the file actually remains open. Only when the
    file is not touched then the OFC expires and the file is
    closed on VMS level.
    
    Adrie
 | |||||
| 4266.4 | Is timing a possibility? | JULIET::HUNG_YU | Yuh-Juan Hung@WRO | Wed Apr 23 1997 09:47 | 15 | 
|     I am assuming the OFC is at VMS level, because we turn off the Open
    File Caching on the PATHWORKS cluster.
    
    How about these file dates changed and stay changed?  She is the only
    user who can access that network drive, so during the copy there will
    not be anybody touching the files.  When the file is finally closed,
    the dates should be (in theory) changed back to the original.
    
    Since the network connection from her building is not perfect
    (sometimes they have network problems from that building connecting to
    the host.), would it be possible that those files did not get closed
    after the OFC_INTERVAL expires?  I am in a different building.
    
    Thanks,
    Yuh-Juan
 | |||||
| 4266.5 | UTRTSC::SWEEP | I want a lolly... | Wed Apr 23 1997 09:50 | 6 | |
|     no
    
    cld time.
    
    adrie
    
 | |||||