File dates
Alan Clifford
When mounting my cameras on linux system (Slackware 10.0), the time in a
photo's exif information is correct but the file time isn't.
File date : 2005:12:22 15:54:52
Date/Time : 2005:12:22 16:54:52
I've checked back and it looks like it started when summer time ended.
When mounted on my Mac powerbook, the date stamp is correct so the culprit
appears to be the linux computer.
The fstab entry is
/dev/sda1 /mnt/camera1 vfat users 0 0
with the camera connected to a usb port which I mount with:
mount /mnt/camera1
I have UTC in /etc/hardwarclock and get the right answer from the date
command:
Thu Dec 22 17:08:59 GMT 2005
Is there a magic incantation for fstab or mount or deep in the bowels of
the usb modules that can solve this problem?
--
Alan
( If replying by mail, please note that all "sardines" are canned.
There is also a password autoresponder but, unless this a very
old message, a "tuna" will swim right through. )
TuxRaider
set the clock in Slackware's setup to local time too, this seems to
resolve any time descrepencies...
Alan Clifford
AC>
AC> When mounting my cameras on linux system (Slackware 10.0), the time in a
AC> photo's exif information is correct but the file time isn't.
AC>
AC> File date : 2005:12:22 15:54:52
AC> Date/Time : 2005:12:22 16:54:52
AC>
I removed usb-storage but couldn't remove usbcore so I rebooted. In a way
I'm a little bit disappointed that the reboot solved the problem.
Next clock change is in March.
Henrik Carlqvist
> I removed usb-storage but couldn't remove usbcore so I rebooted.
Why did you want to remove usbcore? Before doing so you will have to
remove any modules depending on usbcore. This is from my system:
cat /proc/modules
...
usbcore 64992 1 [usbmouse hid usbkbd uhci ehci-hcd]
...
So to remove usbcore I would have to first remove usbmouse, hid, usbkbd,
uhci and ehci-hcd. Removing all those modules would mean that I would no
longer have any usb functionality at all. I prefer to let hotplug handle
the modules for me and I almost never unload any module.
> In a way I'm a little bit disappointed that the reboot solved the
> problem.
Are you really disappointed that you found a method that solved the
problem or are you disappointed that you thought you had to reboot to
solve a problem?
First of all, I don't think you had to reboot to solve the problem, but
most of all I don't think there have been any problem in the first place.
> Next clock change is in March.
Talking about your clock problems it might be a good idea to add some
explanation. Usually Unix systems use UTC time internally. The unix system
has a configuration file to know how to translate the UTC time to the
local time of the system. It is also possible to use the TZ environment
variable to show the date of other timezones. Examples:
$ date
Fri Dec 23 08:25:17 CET 2005
$ date -u
Fri Dec 23 07:25:36 UTC 2005
$ export TZ=UTC
$ date
Fri Dec 23 07:26:02 UTC 2005
$ export TZ=GMT+9
$ date
Thu Dec 22 22:26:26 GMT 2005
$ export TZ=Brazil/West
$ date
Fri Dec 23 03:27:48 AMT 2005
Some simple operating systems do not use UTC time internally. With those
you need to have the local time in your CMOS setup. Then you will also
have to make sure that the time in CMOS setup is adjusted for daylight
savings. Dual booting with such a simple operating system usually means
that you will have to configure Linux to use local time in CMOS.
Your camera is probably running a rather simple OS. That means it is using
local time instead of UTC time. If time stamps in Linux file system is
very important to you it would be possible to change the time in the
camera to UTC time. However, then you would allways see the UTC time in
exif info and on the camera.
regards Henrik
--
The address in the header is only to prevent spam. My real address is:
hc7(at)uthyres.com Examples of addresses which go to spammers:
ro...@variousus.net root@localhost
Alan Clifford
HC> Alan Clifford <sard...@purse-seine.net> wrote:
HC> > I removed usb-storage but couldn't remove usbcore so I rebooted.
HC>
HC> Why did you want to remove usbcore? Before doing so you will have to
HC> remove any modules depending on usbcore. This is from my system:
HC>
HC> cat /proc/modules
HC> ...
HC> usbcore 64992 1 [usbmouse hid usbkbd uhci ehci-hcd]
HC> ...
HC>
HC> So to remove usbcore I would have to first remove usbmouse, hid, usbkbd,
HC> uhci and ehci-hcd. Removing all those modules would mean that I would no
HC> longer have any usb functionality at all. I prefer to let hotplug handle
HC> the modules for me and I almost never unload any module.
HC>
HC> > In a way I'm a little bit disappointed that the reboot solved the
HC> > problem.
HC>
HC> Are you really disappointed that you found a method that solved the
HC> problem or are you disappointed that you thought you had to reboot to
HC> solve a problem?
HC>
HC> First of all, I don't think you had to reboot to solve the problem, but
HC> most of all I don't think there have been any problem in the first place.
HC>
HC> > Next clock change is in March.
HC>
HC> Talking about your clock problems it might be a good idea to add some
HC> explanation. Usually Unix systems use UTC time internally. The unix system
HC> has a configuration file to know how to translate the UTC time to the
HC> local time of the system. It is also possible to use the TZ environment
HC> variable to show the date of other timezones. Examples:
HC>
HC> $ date
HC> Fri Dec 23 08:25:17 CET 2005
HC> $ date -u
HC> Fri Dec 23 07:25:36 UTC 2005
HC> $ export TZ=UTC
HC> $ date
HC> Fri Dec 23 07:26:02 UTC 2005
HC> $ export TZ=GMT+9
HC> $ date
HC> Thu Dec 22 22:26:26 GMT 2005
HC> $ export TZ=Brazil/West
HC> $ date
HC> Fri Dec 23 03:27:48 AMT 2005
HC>
HC> Some simple operating systems do not use UTC time internally. With those
HC> you need to have the local time in your CMOS setup. Then you will also
HC> have to make sure that the time in CMOS setup is adjusted for daylight
HC> savings. Dual booting with such a simple operating system usually means
HC> that you will have to configure Linux to use local time in CMOS.
HC>
HC> Your camera is probably running a rather simple OS. That means it is using
HC> local time instead of UTC time. If time stamps in Linux file system is
HC> very important to you it would be possible to change the time in the
HC> camera to UTC time. However, then you would allways see the UTC time in
HC> exif info and on the camera.
HC>
HC> regards Henrik
HC>
Thanks for the reply but there do seem to be a lot of red herrings in it
I'm afraid. It is clearly the linux system that is at fault and that
fault was flushed by the reboot.
Eef Hartman
> When mounting my cameras on linux system (Slackware 10.0), the time in a
> photo's exif information is correct but the file time isn't.
>
> File date : 2005:12:22 15:54:52
> Date/Time : 2005:12:22 16:54:52
>
> I've checked back and it looks like it started when summer time ended.
> When mounted on my Mac powerbook, the date stamp is correct so the culprit
> appears to be the linux computer.
That is inherent in the different ways Linux (UTC) and Windows (vfat)
handle the DST change. In general Linux is trying to show you what the
UTC date/time, corrected for the LINUX timezone, would have been.
This is because Windows stores files with "local date/time" and Linux
in UTC, buts SHOWS them in current locale time. So the corrections
in Winter and Summer differ by one hour on vfat filesystems and so
date/time on vfat filesystems will normally change by 1 hour twice
a year.
--
********************************************************************
** Eef Hartman, Delft University of Technology, dept. EWI/TW **
** e-mail: E.J.M....@math.tudelft.nl, fax: +31-15-278 7295 **
** snail-mail: P.O. Box 5031, 2600 GA Delft, The Netherlands **
********************************************************************
Henrik Carlqvist
> On Fri, 23 Dec 2005, Henrik Carlqvist wrote:
> HC> Alan Clifford <sard...@purse-seine.net> wrote:
> HC> > I removed usb-storage but couldn't remove usbcore so I rebooted.
> HC>
> HC> Why did you want to remove usbcore?
> HC> > In a way I'm a little bit disappointed that the reboot solved the
> HC> > problem.
> Thanks for the reply but there do seem to be a lot of red herrings in it
> I'm afraid. It is clearly the linux system that is at fault and that
> fault was flushed by the reboot.
But I don't understand what kind of fault you are trying to fix. In your
first message you talk about a problem with file dates, but it doesn't
seem as that was the problem you fixed with a reboot? In your reply to
your own message you talk about removing usb-storage. You also cite some
of the text from your message about file dates. How does your removal of
usb-storage relate to the file date problem? What kind of problem were you
able to fix with a reboot?
Alan Clifford
EH> Alan Clifford <sard...@purse-seine.net> wrote:
EH> > When mounting my cameras on linux system (Slackware 10.0), the time in a
EH> > photo's exif information is correct but the file time isn't.
EH> >
EH> > File date : 2005:12:22 15:54:52
EH> > Date/Time : 2005:12:22 16:54:52
EH> >
EH> > I've checked back and it looks like it started when summer time ended.
EH> > When mounted on my Mac powerbook, the date stamp is correct so the culprit
EH> > appears to be the linux computer.
EH>
EH> That is inherent in the different ways Linux (UTC) and Windows (vfat)
EH> handle the DST change. In general Linux is trying to show you what the
EH> UTC date/time, corrected for the LINUX timezone, would have been.
EH> This is because Windows stores files with "local date/time" and Linux
EH> in UTC, buts SHOWS them in current locale time. So the corrections
EH> in Winter and Summer differ by one hour on vfat filesystems and so
EH> date/time on vfat filesystems will normally change by 1 hour twice
EH> a year.
EH>
Except that the problem was solved by a reboot of the linux computer.
Alan Clifford
HC> But I don't understand what kind of fault you are trying to fix. In your
HC> first message you talk about a problem with file dates, but it doesn't
HC> seem as that was the problem you fixed with a reboot? In your reply to
HC> your own message you talk about removing usb-storage. You also cite some
HC> of the text from your message about file dates. How does your removal of
HC> usb-storage relate to the file date problem? What kind of problem were you
HC> able to fix with a reboot?
HC>
The problem is pretty simple but the solution seems elusive. The
photograph in question was taken at 16:54:52, as shown in the exif data.
When the camera was mounted on the linux computer, the file date was shown
as 15:54:52 (When mounted on my Mac power book, the file date was shown as
16:54:52)
File date : 2005:12:22 15:54:52
Date/Time : 2005:12:22 16:54:52
The linux computer is rebooted (nothing has changed on the camera nor on
memory card in the camera). When the camera is mounted on the linux
computer the file date shown is 16:54:52
File date : 2005:12:22 16:54:52
Date/Time : 2005:12:22 16:54:52
I don't want to rely on the kludge of rebooting the computer in March when
the problem will no doubt re-occur after British Summer Time has kicked
in. I perceive that it is a problem with the usb system. I couldn't
manually remove all the modules and probably data caches but a reboot
did.
Henrik Carlqvist
> Except that the problem was solved by a reboot of the linux computer.
To me it sounds a bit strange that you were able to fix the date problem
only by doing a reboot. However, the important thing is that it works. I
don't think the usb-core module should have anything to do with the time
stamps on the files. The relevant part should be the vfat file system
driver which usually is built into the kernel.
Alan Clifford
HC> Alan Clifford <sard...@purse-seine.net> wrote:
HC> > Except that the problem was solved by a reboot of the linux computer.
HC>
HC> To me it sounds a bit strange that you were able to fix the date problem
HC> only by doing a reboot. However, the important thing is that it works. I
HC> don't think the usb-core module should have anything to do with the time
HC> stamps on the files. The relevant part should be the vfat file system
HC> driver which usually is built into the kernel.
HC>
Ok thanks. It seem worth a kernel recompile to use the FAT stuff as
modules before March. Then they could be unloaded.
Karl
> On Sat, 24 Dec 2005, Henrik Carlqvist wrote:
>
> HC> Alan Clifford <sard...@purse-seine.net> wrote:
> HC> > Except that the problem was solved by a reboot of the linux computer.
> HC>
> HC> To me it sounds a bit strange that you were able to fix the date problem
> HC> only by doing a reboot. However, the important thing is that it works. I
> HC> don't think the usb-core module should have anything to do with the time
> HC> stamps on the files. The relevant part should be the vfat file system
> HC> driver which usually is built into the kernel.
> HC>
>
> Ok thanks. It seem worth a kernel recompile to use the FAT stuff as
> modules before March. Then they could be unloaded.
>
Just wondering, instead of rebooting I wonder if doing a "telinit 1" in
console and going back to the slacks default runlevel of "telinit 3"
would have done the trick maybe?
Karl
Eef Hartman
> Just wondering, instead of rebooting I wonder if doing a "telinit 1" in
> console and going back to the slacks default runlevel of "telinit 3"
> would have done the trick maybe?
Shouldn't do anything usefull, telinit only restarts "other" programs,
not the kernel (and the init process) itself, nor does it reload kernel
modules. So vfat support will stay the same, while a _reboot_ will
reload the whole system, including the kernel.