| 2009-10-23 11:54:05 |
Tormod Volden |
bug |
|
|
added bug |
| 2009-10-23 11:54:05 |
Tormod Volden |
attachment added |
|
change times on the vfat partition http://launchpadlibrarian.net/34245593/media-DATA-old-mod-time-stat-Change |
|
| 2009-10-23 11:54:05 |
Tormod Volden |
attachment added |
|
Dependencies.txt http://launchpadlibrarian.net/34245594/Dependencies.txt |
|
| 2009-10-23 11:57:54 |
Tormod Volden |
description |
Many of my files have gotten a modification time of "1980-01-01 00:00:00" on a vfat partition, or "1940-10-24 02:26:18" on my ext3 root partition. Only files are affected, not directories.
Only files in my home directory are affected on the root partition, on the vfat partition only files in a directory which I had a shortcut or link for on my desktop and in my Nautilus bookmarks. I therefore think it is a user program that is doing something bad.
Earlier suspicions were vfat (but I have now seen it on ext3), nautilus (but I have seen it in directories I never browsed with nautilus), tracker (I have uninstalled it). I am using a pretty standard Gnome setup.
The change times of the affected files are grouped together in spans of several minutes or hours, so it can seem like there is a program/daemon going through file trees and messing up modification times.
For instance, in my home directory, almost all the file inodes concerned were changed between 11:54:17-11:54:26 (4000 files) or 11:55:01-11:55:10 (900 files) on 2009-10-14.
On the vfat partition, 2008-07-14 14:14:24-14:16:53 (4000 files) then some other dates as well. I will attach the "stat | grep ^Change" list for this partition. There are some "holes" of several seconds where no inodes were updated. I wonder if it is some kind of "niced" process that takes a pause if something else using the system.
In some directories some files have kept their valid modification time, but their change time is the same as for those files in the same directory which had their modification time reset.
This is so far a vague bug report, because I have no idea what is going on. I am not sure which package is responsible if any. However I file it to track my own investigation and to see if other people have experienced this.
ProblemType: Bug
Architecture: i386
DistroRelease: Ubuntu 9.04
Package: ubuntu-standard 1.140
ProcEnviron:
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: ubuntu-meta
Uname: Linux 2.6.31-11-generic i686 |
Many of my files have gotten a modification time of "1980-01-01 00:00:00" on a vfat partition, or "1940-10-24 02:26:18" on my ext3 root partition. Only files are affected, not directories.
Only files in my home directory are affected on the root partition, on the vfat partition only files in a directory which I had a shortcut or link for on my desktop and in my Nautilus bookmarks. I therefore think it is a user program that is doing something bad.
Earlier suspicions were vfat (but I have now seen it on ext3), nautilus (but I have seen it in directories I never browsed with nautilus), tracker (I have uninstalled it).
The change times of the affected files are grouped together in spans of several minutes or hours, so it can seem like there is a program/daemon going through file trees and messing up modification times.
For instance, in my home directory, almost all the file inodes concerned were changed between 11:54:17-11:54:26 (4000 files) or 11:55:01-11:55:10 (900 files) on 2009-10-14.
On the vfat partition, 2008-07-14 14:14:24-14:16:53 (4000 files) then some other dates as well. I will attach the "stat | grep ^Change" list for this partition. There are some "holes" of several seconds where no inodes were updated. I wonder if it is some kind of "niced" process that takes a pause if something else using the system.
In some directories some files have kept their valid modification time, but their change time is the same as for those files in the same directory which had their modification time reset.
I am using a pretty standard Gnome setup. The only "special" with my setup is the use of dmraid mirror, but I don't see how that would reset mtimes without messing other things up.
This is so far a vague bug report, because I have no idea what is going on. I am not sure which package is responsible if any. Anyway I am filing it to track my own investigation and to see if other people have experienced this.
ProblemType: Bug
Architecture: i386
DistroRelease: Ubuntu 9.04
Package: ubuntu-standard 1.140
ProcEnviron:
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: ubuntu-meta
Uname: Linux 2.6.31-11-generic i686
|
|
| 2009-10-23 12:06:32 |
Tormod Volden |
attachment added |
|
sort -u on the same list to see "holes" in time http://launchpadlibrarian.net/34246412/media-DATA-old-mod-time-stat-Change.sort-u |
|
| 2009-10-23 12:08:21 |
Tormod Volden |
affects |
ubuntu-meta (Ubuntu) |
ubuntu |
|
| 2009-10-23 13:53:52 |
Tormod Volden |
description |
Many of my files have gotten a modification time of "1980-01-01 00:00:00" on a vfat partition, or "1940-10-24 02:26:18" on my ext3 root partition. Only files are affected, not directories.
Only files in my home directory are affected on the root partition, on the vfat partition only files in a directory which I had a shortcut or link for on my desktop and in my Nautilus bookmarks. I therefore think it is a user program that is doing something bad.
Earlier suspicions were vfat (but I have now seen it on ext3), nautilus (but I have seen it in directories I never browsed with nautilus), tracker (I have uninstalled it).
The change times of the affected files are grouped together in spans of several minutes or hours, so it can seem like there is a program/daemon going through file trees and messing up modification times.
For instance, in my home directory, almost all the file inodes concerned were changed between 11:54:17-11:54:26 (4000 files) or 11:55:01-11:55:10 (900 files) on 2009-10-14.
On the vfat partition, 2008-07-14 14:14:24-14:16:53 (4000 files) then some other dates as well. I will attach the "stat | grep ^Change" list for this partition. There are some "holes" of several seconds where no inodes were updated. I wonder if it is some kind of "niced" process that takes a pause if something else using the system.
In some directories some files have kept their valid modification time, but their change time is the same as for those files in the same directory which had their modification time reset.
I am using a pretty standard Gnome setup. The only "special" with my setup is the use of dmraid mirror, but I don't see how that would reset mtimes without messing other things up.
This is so far a vague bug report, because I have no idea what is going on. I am not sure which package is responsible if any. Anyway I am filing it to track my own investigation and to see if other people have experienced this.
ProblemType: Bug
Architecture: i386
DistroRelease: Ubuntu 9.04
Package: ubuntu-standard 1.140
ProcEnviron:
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: ubuntu-meta
Uname: Linux 2.6.31-11-generic i686
|
Many of my files have gotten a modification time of "1980-01-01 00:00:00" on a vfat partition, or "1940-10-24 02:26:18" on my ext3 root partition. Only normal files are affected, not directories.
Only files in my home directory are affected on the root partition, and on the vfat partition only files in a directory for which I had a shortcut or link on my desktop and in my Nautilus bookmarks. I therefore think it is a user program that is doing something bad.
Earlier suspicions were vfat (but I have now seen it on ext3), nautilus (but I have seen it in directories I never browsed with nautilus), tracker (I have uninstalled it).
The change times of the affected files are grouped together in spans of several minutes or hours, so it can seem like there is a program/daemon going through file trees and messing up modification times.
For instance, in my home directory, almost all the file inodes concerned were changed between 11:54:17-11:54:26 (4000 files) or 11:55:01-11:55:10 (900 files) on 2009-10-14.
On the vfat partition, 2008-07-14 14:14:24-14:16:53 (4000 files) then some other dates as well. I will attach the "stat | grep ^Change" list for these files. There are some "holes" of several seconds where no inodes were updated. I wonder if it is some kind of "niced" process that takes a pause if something else using the system.
In some directories some files have kept their correct modification time, but their change time is the same as for those files in the same directory which had their modification time reset.
I am using a pretty standard Gnome setup. The only "special" with my setup is the use of dmraid mirror, but I don't see how that would reset mtimes without messing other things up.
This is so far a vague bug report, because I have no idea what is going on. I am not sure which package is responsible if any. Anyway I am filing it to track my own investigation and to see if other people have experienced this.
ProblemType: Bug
Architecture: i386
DistroRelease: Ubuntu 9.04
Package: ubuntu-standard 1.140
ProcEnviron:
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: ubuntu-meta
Uname: Linux 2.6.31-11-generic i686
|
|
| 2010-08-27 21:15:06 |
David Tombs |
ubuntu: status |
New |
Incomplete |
|
| 2010-12-15 04:20:22 |
Launchpad Janitor |
ubuntu: status |
Incomplete |
Expired |
|
