Re: File ctime/mtime update inconsistencies - Samba

This is a discussion on Re: File ctime/mtime update inconsistencies - Samba ; On Tue, Jul 08, 2008 at 01:16:51PM +0300, Atte Peltomaki wrote: > Problem: neither ctime nor mtime attributes are consistently updated > when new files are created or existing ones replaced. Another thing I would like to address is timestamps ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Re: File ctime/mtime update inconsistencies

  1. Re: File ctime/mtime update inconsistencies

    On Tue, Jul 08, 2008 at 01:16:51PM +0300, Atte Peltomaki wrote:
    > Problem: neither ctime nor mtime attributes are consistently updated
    > when new files are created or existing ones replaced.


    Another thing I would like to address is timestamps for large files. In
    addition to consistently updating c/mtime, I think it would make sense
    to update the stamp also *after* file transfer has completed. This would
    allow eg. rsync to identify changed files without expensive
    checksumming.

    Would these changes be accepted in mainstream, if I send patches?
    (Against 3.2).

    --
    ____________
    \ ______// Atte Peltomäki - atte.peltomaki@f-secure.com
    \ \\____ UNIX System Administrator - IT Server Team
    \ __// F-Secure Corp. PL 24, FIN-00181 Helsinki, Finland
    \ \\ Tel: +358 9 2520 0700, direct: +358 9 2520 5423
    \ // http://www.f-secure.com
    \/ Integrated Solutions for Enterprise Security


  2. Re: File ctime/mtime update inconsistencies

    On Thu, Jul 10, 2008 at 12:40:34PM +0300, Atte Peltomaki wrote:
    > On Tue, Jul 08, 2008 at 01:16:51PM +0300, Atte Peltomaki wrote:
    > > Problem: neither ctime nor mtime attributes are consistently updated
    > > when new files are created or existing ones replaced.

    >
    > Another thing I would like to address is timestamps for large files. In
    > addition to consistently updating c/mtime, I think it would make sense
    > to update the stamp also *after* file transfer has completed. This would
    > allow eg. rsync to identify changed files without expensive
    > checksumming.
    >
    > Would these changes be accepted in mainstream, if I send patches?
    > (Against 3.2).


    Timestamps are a very tricky problem. Any patches sent would
    have to pass the Samba4 smbtorture tests. This is not as easy
    as it sounds :-). But yes, I'm willing to look at any patches
    submitted.

    Jeremy.


  3. Re: File ctime/mtime update inconsistencies

    From looking at an old truss, I suspect you want to update
    the timestamp before you call close on the file. Whether
    that's entirely sufficient for Windows client foolishness
    I can't say (but smbtorture will (;-))

    --dave

    Jeremy Allison wrote:
    > On Thu, Jul 10, 2008 at 12:40:34PM +0300, Atte Peltomaki wrote:
    >
    >>On Tue, Jul 08, 2008 at 01:16:51PM +0300, Atte Peltomaki wrote:
    >>
    >>>Problem: neither ctime nor mtime attributes are consistently updated
    >>>when new files are created or existing ones replaced.

    >>
    >>Another thing I would like to address is timestamps for large files. In
    >>addition to consistently updating c/mtime, I think it would make sense
    >>to update the stamp also *after* file transfer has completed. This would
    >>allow eg. rsync to identify changed files without expensive
    >>checksumming.
    >>
    >>Would these changes be accepted in mainstream, if I send patches?
    >>(Against 3.2).

    >
    >
    > Timestamps are a very tricky problem. Any patches sent would
    > have to pass the Samba4 smbtorture tests. This is not as easy
    > as it sounds :-). But yes, I'm willing to look at any patches
    > submitted.
    >
    > Jeremy.
    >


    --
    David Collier-Brown | Always do right. This will gratify
    Sun Microsystems, Toronto | some people and astonish the rest
    davecb@sun.com | -- Mark Twain
    (905) 943-1983, cell: (647) 833-9377, (800) 555-9786 x56583
    bridge: (877) 385-4099 code: 506 9191#


+ Reply to Thread