[issue10148] st_mtime differs after shutil.copy2

2012-05-05 Thread Roundup Robot
Roundup Robot added the comment: New changeset 05274ab06182 by Larry Hastings in branch 'default': Update Misc/NEWS for issues #14127 and #14705. (And, technically, #10148.) http://hg.python.org/cpython/rev/05274ab06182 -- ___ Python tracker

[issue10148] st_mtime differs after shutil.copy2

2012-05-05 Thread Roundup Robot
Roundup Robot added the comment: New changeset 709850f1ec67 by Larry Hastings in branch 'default': Update Misc/NEWS for issues #14127 and #14705. (And, technically, #10148.) http://hg.python.org/cpython/rev/709850f1ec67 -- nosy: +python-dev ___ Pyth

[issue10148] st_mtime differs after shutil.copy2

2012-03-13 Thread STINNER Victor
STINNER Victor added the comment: This issue is a duplicate of #14127. -- nosy: +haypo resolution: -> duplicate status: open -> closed ___ Python tracker ___ __

[issue10148] st_mtime differs after shutil.copy2

2011-04-27 Thread Arfrever Frehtes Taifersar Arahesis
Arfrever Frehtes Taifersar Arahesis added the comment: Python >=3.3 contains os.futimens() and os.utimensat() functions. I have filed issue #11941, which suggests to add support for nanosecond resolution in result of os.stat(). -- ___ Python tracke

[issue10148] st_mtime differs after shutil.copy2

2011-04-27 Thread Éric Araujo
Changes by Éric Araujo : -- nosy: +eric.araujo ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyth

[issue10148] st_mtime differs after shutil.copy2

2011-01-28 Thread Arfrever Frehtes Taifersar Arahesis
Changes by Arfrever Frehtes Taifersar Arahesis : -- nosy: +Arfrever ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

[issue10148] st_mtime differs after shutil.copy2

2011-01-28 Thread Peter
Peter added the comment: I'm also seeing this on 32bit Windows XP using Python 3.1.2, and Python 3.2rc1 on a local NTFS filesystem. e.g. from os.stat(filename).st_mtime after using shutil.copy2(...) 1293634856.1402586 source 1293634856.1402581 copied I've been using shutil.copy2 then expecti

[issue10148] st_mtime differs after shutil.copy2

2010-10-19 Thread Martin v . Löwis
Martin v. Löwis added the comment: This is a system limitation. The underlying file system supports nanosecond resolution for the file stamps, and stat(2) also supports reporting them. However, utimes(2) only supports microsecond resolution when setting them. Linux supports utimensat(2) since

[issue10148] st_mtime differs after shutil.copy2

2010-10-19 Thread Luke McCarthy
New submission from Luke McCarthy : When copying a file with shutil.copy2() between two ext4 filesystems on 64-bit Linux, the mtime of the destination file is different after the copy. It appears as if the resolution is slightly different, so the mtime is truncated slightly. For example: sour