Bug in NTFS - date values are preserved

Discussion in 'Windows Vista Drivers' started by atlan, Aug 29, 2006.

  1. atlan

    atlan Guest

    I have found a logical bug in NTFS (NTFS4 and NTFS5).

    Reproduction:

    1. create folders "folderA" and "folderB"

    2. in "folderA" create a textfile called "file.txt"

    3. now increase your system clock by one hour

    4. in "folderB" create a textfile called "file.txt"

    5. check the creation date of the files
    "folderA\file.txt" will be one hour older than "folderB\file.txt"

    6. now copy the younger "folderB\file.txt" to "folderA" and overwrite
    the existing file

    7. now the bug: the creation, modification and access dates of
    "folderA\file.txt" have NOT changed. Instead their values are preserved
    from the file that existed before. As normal behaviour I would have
    expected that these values will be overwritten by the values of the
    newer file. To make it more worse. The values are preserverd for 10
    seconds. Which means if you delete the file in "folderA" the file
    copied from "folderB" will still get the preserved values within this
    time period.

    For me this is a logical bug when you think of all the other attributes
    that will be copied 1:1 from "folderB\file.txt" to "folderA\file.txt"
    like:

    - security settings
    - attributes
    - streams

    I think this problem should be fixed.


    Best regards,
    Holger
     
    atlan, Aug 29, 2006
    #1
    1. Advertisements

  2. 6. now copy the younger "folderB\file.txt" to "folderA" and overwrite
    Looks like a shell bug and not NTFS bug. Have you tried to do this from
    CMD.EXE?
     
    Maxim S. Shatskih, Aug 29, 2006
    #2
    1. Advertisements

  3. atlan

    Code Jockey Guest

    Logically, it would seem to be a bug. Actually, it is by design.

    http://support.microsoft.com/?kbid=172190

    The file retains certain attributes if it is re-created within 15 seconds
    (default) of its deletion. The time can be adjusted or the feature can be
    disabled, according to instructions in the link.
     
    Code Jockey, Aug 30, 2006
    #3
  4. fyi, this is called tunnelling (IIRC)

    d
     
    Doron Holan [MS], Aug 30, 2006
    #4
  5. atlan

    atlan Guest

    Thank you. Now the behaviour is explainable and can be disabled.
    Is there some sort of overview that will describe all the DOS
    compatibility switches still active in Windows 200x , XP and beyond?

    Holger
     
    atlan, Aug 30, 2006
    #5
  6. atlan

    atlan Guest

    When you disable tunneling the creation date is not cached anymore.
    This means the creation date will be replaced when you do this:

    - file exists
    - delete existing file
    - copy file into directory with same name
    => creation date is set to the date of the new file
    => OK

    But the creation date is still preserved when you do this (despite
    setting MaximumTunnelEntries=0 and MaximumTunnelEntryAgeInSeconds=0:

    - file exists
    - replace file with new file
    => creation date is still the old one
    => BUG

    Is there any other switch to disable this anoying behavour?

    Best regards,
    Holger
     
    atlan, Sep 4, 2006
    #6
  7. What you mean "replace file with new file"? Create the file by truncating an
    existing one? Then the file still exists and its creation date should not
    change.
     
    Alexander Grigoriev, Sep 5, 2006
    #7
  8. atlan

    atlan Guest

    I am refering to my 7 steps to reproduce the problem (my initial
    posting).

    Tunneling is disabled via registry (plus restart of computer) and then
    you execute the 7 steps => creation date is not replaced when you copy
    via explorer => BUG.
    Of course it should change. I have disabled tunneling and all these
    attributes will be replaced on the existing file:

    - security settings
    - attributes
    - streams

    But still NTFS is not copying the date values which is plain wrong
    behaviour.


    Best regards,
    Holger
     
    atlan, Sep 5, 2006
    #8
  9. - file exists
    When a file is replaced, it's not deleted.
     
    Alexander Grigoriev, Sep 5, 2006
    #9
  10. atlan

    atlan Guest

    - file exists
    Well, I do not see where this helps me with my problem. The behaviour
    of NTFS has flaws in its logic. I see that tunneling has been
    implemented for backward compatibility and I understand why this is so.
    Now, I have choosen to deactivate tunneling and still the creation
    dates are preserved when files get replaced. I need a solution where
    these dates are set to the dates of the new file when the user operates
    with the explorer.

    Please try to understand what I am trying to achieve. It is important
    for me that this behaviour is fixed.

    Best regards,
    Holger
     
    atlan, Sep 5, 2006
    #10
  11. Don't use creation time. Use last modification time which follows the file.
     
    Alexander Grigoriev, Sep 6, 2006
    #11
  12. atlan

    atlan Guest

    Don't use creation time. Use last modification time which follows the file.

    First of all there is a logical bug in NTFS and there is no switch to
    get around it.

    If this is true - and it looks like it is proofen - then we can argue
    this to our customer and draw the right conclusions from it.

    => it would like to see this fixed by Microsoft.
     
    atlan, Sep 6, 2006
    #12
  13. atlan

    Ian Abbott Guest

    Ian Abbott, Sep 6, 2006
    #13
  14. atlan

    atlan Guest

    It's not a bug, it's documented behavior. Check the "Remarks" section
    Thank you for your hint. So there are two factors here and it gets more
    confusing. You expect the Windows Explorer to use the API function
    ReplaceFile. So far I have used CopyFile(a,b,FALSE) which will replace
    files too - and there is no such remarks section:

    -Tunneling itself preserves the dates
    -ReplaceFile behaviour preserves the dates (called major advantage ;-)

    I addition I find confusing that ReplaceFile is expected to preserve
    Streams and Security Settings (DACL). When I am using the Windows
    Explorer to replace a file I experience a behaviour different from
    that:

    -DACL is preserved
    -Streams are not preserved nor added upon (Remark says: also preserves
    the following attributes of the original file: Named streams not
    already in the replacement file).

    At least there are inconsistencies in the API documentation:

    -is CopyFile(a,b,FALSE) using ReplaceFile and will the behaviour be the
    same as described in the remarks section of ReplaceFile?

    -why are Streams not preserved when you replace a file plus stream with
    a file without stream?


    Best regards,
    Holger
     
    atlan, Sep 7, 2006
    #14
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.