Package: lightning
Version: 1:45.6.0-3
Severity: normal
Dear maintainer,
Some packaged files have fake, constant modification times, as can for
instance be seen here:
ll --full-time usr/lib/lightning/
total 40
-rw-r--r-- 1 peter peter 563 2010-01-01 01:00:00.000000000 +0100 app.ini
drwxr-xr-x 2 peter peter 4096 2017-01-18 00:26:06.000000000 +0100 calendar-js
drwxr-xr-x 6 peter peter 4096 2017-01-23 15:18:24.237512811 +0100 chrome
-rw-r--r-- 1 peter peter 5953 2010-01-01 01:00:00.000000000 +0100
chrome.manifest
drwxr-xr-x 2 peter peter 4096 2017-01-18 00:26:06.000000000 +0100 components
drwxr-xr-x 3 peter peter 4096 2017-01-18 00:26:06.000000000 +0100 defaults
-rw-r--r-- 1 peter peter 1772 2010-01-01 01:00:00.000000000 +0100 install.rdf
drwxr-xr-x 2 peter peter 4096 2017-01-18 00:26:06.000000000 +0100 modules
drwxr-xr-x 2 peter peter 4096 2017-01-18 00:26:06.000000000 +0100 timezones
Why is this a problem? It's a problem when people use certain backup
solutions. For instance, I use dirvish, which underneath uses rsync with
a --link-dest argument set to the previous backup. Rsync by default
inspects file metadata only to see if it needs to transfer anything. If
mode, mtime and *size* all stay the same, rsync concludes that the file
is unchanged and hardlinks to the file present in the previous backup.
Periodically, I let rsync run with the --checksum argument to check the
integrity of my backups. That's when I discovered these files had
changed only in data, but not in mtime or size:
usr/lib/iceowl-extension/chrome/calendar-en-US/locale/en-US/calendar/menuOverlay.dtd
usr/lib/iceowl-extension/chrome/calendar/content/calendar/calendar-dnd-listener.js
usr/lib/iceowl-extension/chrome/calendar/content/calendar/calendar-migration-dialog.js
usr/share/firefox-esr/browser/defaults/preferences/devtools.js
usr/share/firefox-esr/browser/defaults/preferences/firefox.js
usr/share/firefox-esr/browser/defaults/preferences/webide-prefs.js
This is on Debian stable. All of these files differed just in comments,
/except/ for
usr/lib/iceowl-extension/chrome/calendar-en-US/locale/en-US/calendar/menuOverlay.dtd:
diff -ur
20170121-0302/tree/usr/lib/iceowl-extension/chrome/calendar-en-US/locale/en-US/calendar/menuOverlay.dtd
20170122-0307/tree/usr/lib/iceowl-extension/chrome/calendar-en-US/locale/en-US/calendar/menuOverlay.dtd
---
20170121-0302/tree/usr/lib/iceowl-extension/chrome/calendar-en-US/locale/en-US/calendar/menuOverlay.dtd
2010-01-01 01:00:00.000000000 +0100
+++
20170122-0307/tree/usr/lib/iceowl-extension/chrome/calendar-en-US/locale/en-US/calendar/menuOverlay.dtd
2010-01-01 01:00:00.000000000 +0100
@@ -47,4 +47,4 @@
<!ENTITY showCurrentView.accesskey "V">
<!ENTITY calendar.properties.label "Calendar Properties…">
-<!ENTITY calendar.properties.accesskey "C">
+<!ENTITY calendar.properties.accesskey "a">
Apparently at some time in the past, an updated iceowl-extension package
shipped a new file where this "accesskey" changed from a C to an a. At
that moment, my backups no longer reflected the files on the system. If
I were to restore from backup, the old file with the old C access key
would be restored, and my system's behaviour would have changed because
of it.
I suggest these synthetic, fake mtimes should be fixed to reflect actual
changes. I can't believe that someone wrote the two versions of
menuOverlay.dtd with two different access keys in the same, very first
second of 2010, so why does the mtime reflect that this is what
happened? It confuses backup tools because we don't have the Archive
attribute that MS-DOS could use for these purposes. Instead they rely on
truthful metadata, where the mtime is the last time the file content was
changed, not some fake piece of non-information.
Thanks for your packaging efforts,
Peter.
-- System Information:
Debian Release: 8.7
APT prefers stable-updates
APT policy: (990, 'stable-updates'), (990, 'stable'), (610, 'testing'), (600,
'unstable'), (500, 'testing-updates'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.8.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
