atime is not preserved on restore

[Germar]

From Debian report:

i:Exit -:PrevPg <Space>:NextPg v:View Attachm. d:Del r:Reply j:Next ?:Help Date: Sat, 27 Aug 2011 22:33:17 +0100
From: Julian Gilbey

Package: backintime-gnome Version: 1.0.8-1 Severity: normal

Hi!
When backintime performs a backup, it does not preserve the file
access time. This means that mailbox-checking programs, such as mutt,
lose the information as to when the mailbox was last actually read.
I would recommend that backintime does something like
orig_times = os.stat(file)
[perform whichever actions required on file]
os.utime(file, (orig_times.st_atime, orig_times.st_mtime))

whenever it needs to read a file for backup purposes.

Julian

---

Imported from Launchpad using lp2gh.

• date created: 2011-08-28T14:38:23Z
• owner: jwiltshire
• the launchpad url was https://bugs.launchpad.net/bugs/836077

[Wabuo]

I may experienced the same today ... Some folders on the backup now show 2./3. Jan. 1970 as last changing time.

[Germar]

Hmmm, 2./3. Jan. 1970 is really strange.

I understood this bugreport as the atime of files where changed to current date/time while rsync synced them. Which is totally normal and nothing I can do about. Rsync need to read the files and so the filesystem will change atime. (there is a patch for rsync which will add an argument -U to avoid this but non of those distributions i checked used that patch during build)

But this has nothing to do with your case. You're talking about mtime. Which filesystem and rsync version do you use? Oh and could you please open a new bug report for this?

[Wabuo]

@Germar I won't open a new issue because I found more files with strange dates on the same external hard drive which were never touched by BIT.

[emtiu]

Keeping this open as a reminder more than a to-do.