Results 1 to 3 of 3
  1. #1
    Super Moderator BATcher's Avatar
    Join Date
    Feb 2008
    A cultural area in SW England
    Thanked 212 Times in 189 Posts
    I am probably pushing my luck here, but I have been unable to find hard information about what is the file timestamp granularity on any of the *nix-based file systems, like ext, ext2, ext3, ext4, Reiser and the like.

    All us Microsoft chaps know that the timestamp granularity of files in the various file systems is as follows:
    FAT - 2 seconds
    exFAT - 10 milliseconds
    NTFS - 100 nanoseconds

    All I can find is the unverified statement that
    "Linux with ext2/ext3 has 1-second timestamp granularity".

    There are two separate issues here as well:
    * the resolution of the file timestamps held on the hard disk directory/index/whatever
    * the resolution of the file timestamps reported to user programs (like backup)

    Why do I care about this? My recently-acquired NAS (believed to run under Xenix) gives the appearance of being formatted with NTFS but in practice it does not seem to return the NTFS timestamp resolution. If you compare the timestamps of the same file held on a 'real' NTFS system with that on the NAS, they can be different by 2 or (rarely) more seconds. This difference is important when you are trying to copy only 'changed' files from a 'real' NTFS disk to the NAS, because most of the time the same file will appear to be up to a couple of seconds older on the NAS, so a copy will usually be scheduled to take place even though the content of the files is identical. With ROBOCOPY, for example, you have to specify the /FFT option, which means "consider source and target files to be identical if their timestamps differ by 2 seconds or less", and even then there will still be some files copied (because the source file is thought to be newer) even though I'm petty certain they are the same file.

    Some stats for your amusement, for identical copies:

    Without /FFT switch
    				Total	  Copied	 Skipped
    	Files :	573566	  184068	  389498
    	Bytes :   244.405 GB  161.705 GB   82.700 GB
    With /FFT switch 
    				Total	  Copied	 Skipped
    	Files :	573566	   14382	  559184
    	Bytes :   244.405 GB   31.816 GB  212.589 GB
    Has anyone done any work in this area?

    Mission: identify what we do best and find more ways of doing less of it better

  2. #2
    New Lounger
    Join Date
    Dec 2009
    Big D,Texas,USA
    Thanked 0 Times in 0 Posts
    I may be late to respond to this, but it's because I just found out about this forum today and this is the first time I'm browsing through it.

    Anyhow, since nobody has responded to this I'll post a comment.

    All UNIX/Linux filesystems historically use a 1 second resolution timestamp, that is until just recently with the new ext4 filesystem, which uses a 1 nanosecond timestamp.

    A pretty good reference -->

    But even though ext4 meets your needs, Samba does not because it will still use the 1 second resolution, at least until it gets updated for this, if ever.

  3. #3
    New Lounger
    Join Date
    Apr 2014
    Thanked 0 Times in 0 Posts
    I was trying to do the exact same thing as BATcher and ran into the same problem. I was using Java to write my backup program which provides the time in units of msecs, so I logged the source and target times. I was getting things like source time = nnnnnnnnn383 and target time = nnnnnnnnn000. There you go, resolution of seconds from my NAS. So I just coded my condition to replace a file as IF (sourceTm > (targetTm + 999)) and got the desired behavior.

    Why didn't EVERY file appear to need replacement? I had recently replaced my computer and populated its hard drive from the NAS where the backups had previously been done by hand.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts