On 2014-10-03 19:09, Istvan Gabor wrote:

"Carlos E. R." írta:

You miss the point. People arrange their life according to local time, not to time zones. Let's take another example. Suppose I have lunch every day at 12.00 local time be it winter or summer. If I take a photo at 12:45 I know I took it after lunch. If the OS interprets the time as 11:45 I think it was taken before lunch. Big difference. What you are saying implies that I should recalculate when the photo was taken taking into account winter/summer time. That is nonsense. I expect the OS to do it form me.

What I say is that the system appears to be adjusting the timestamp for display according to the current difference of timezone + daylight shift. Not according to what was valid at the time the photo was taken. And this may be a side effect of VFAT handling in Linux. Or maybe not. You have to use the internal exif timestamp, not the file timestamp. It is not reliable. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 10/3/2014 12:09 PM, Istvan Gabor wrote:

But I have a question:

If I take a photo now and mount the card right after it (practically within the same daylight shift period) the time stamp reflects the current local time correctly (as expected). If I leave this file on the hard drive and wait for a few weeks or months until the daylight shift period has changed (for example from summer time to winter time) will the time stamp of this file be changed (shifted by an hour) on my hard drive (ext3 filesystem)? I haven't tried so I am not sure, bu I expect that the time stamp won't change after the time shift. Is this correct?

Files on your hard drive will not have the time shifted by daylight saving time changes because they are invariably written in UTC on modern distros. There are/were some file utilities that adjusted the presentation of the time, and these would show times in the future for files just written at the moments before "fall back" time, but I think this is no longer a common problem. -- _____________________________________ ---This space for rent--- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 10/3/2014 1:14 PM, Istvan Gabor wrote:

John Andersen írta:

...

On 10/3/2014 12:09 PM, Istvan Gabor wrote:

...

But I have a question:

If I take a photo now and mount the card right after it (practically within the same daylight shift period) the time stamp reflects the current local time correctly (as expected). If I leave this file on the hard drive and wait for a few weeks or months until the daylight shift period has changed (for example from summer time to winter time) will the time stamp of this file be changed (shifted by an hour) on my hard drive (ext3 filesystem)? I haven't tried so I am not sure, bu I expect that the time stamp won't change after the time shift. Is this correct?

Files on your hard drive will not have the time shifted by daylight saving time changes because they are invariably written in UTC on modern distros.

And it is normal and expected. So if I do the copying the way I described above, after the time shift the file still has the correct local time time-stamp. But if I mount the card after the time shift the time-stamp will be shifted. That is the time-stamps will differ only because the files were copied at different times (ie the filesystems were mounted at different times). I consider this a buggy behavior. The time stamp should always be the same for the same file and shouldn't depend on when the filesystem is mounted.

Istvan

Agreed, in a perfect world that would be the case. But I've been bitten more than once crossing systems, and there must be some bugs or you wouldn't have started the thread. What would you think is the most expedient way to get beyond this issue? File bug reports and hold off doing anything till these are handled? Use exiv2 to set the date/time to the EXIF info? Use exiv2 to change the file name to EXIF date-time-suffix and forever not worry about this bug? Given that you found it to be broken, I suspect the way you fix it is going to but up to you, but one think I know won't work in a timely manor is the bug report route. Been there. Done that. Bought the T-shirt. Its worn out already. -- _____________________________________ ---This space for rent--- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 10/3/2014 3:31 PM, Patrick Shanahan wrote:

* John Andersen [10-03-14 17:19]: [...]

...

What would you think is the most expedient way to get beyond this issue? File bug reports and hold off doing anything till these are handled? Use exiv2 to set the date/time to the EXIF info? Use exiv2 to change the file name to EXIF date-time-suffix and forever not worry about this bug?

exiv2 mv \-k \-r %y%m%d_%H%M%S_:basename: \.\/*.{nef,NEF,jpg,JPG}

Something odd about this script to be aware of... It might be wise to not use the _:basename: portion, because if you do, it keeps appending old file names onto each file and they get longer and longer and longer. Common work flow might include adding files to a directory, then running this command. But previously existing files, upon which you had previously run the command will have the the new file name followed by the old file followed by the older file name, until you end up with something like this: 130317_170416_130317_170416_130317_170416_130317_170416_130317_170416_DSC00514.JPG Also if you have older pictures you might want a more rational sort order by inclding the Century so instead of %y%m%d_%H%M%S you might want %Y%m%d_%H%M%S (note the Y must be upper case). And you could also add something (anything) behind the %y%m%d_%H%M%S to jog your memory, such as %y%m%d_%H%M%S_Italy. One could argue that belongs in the EXIF info, but its often easier locate stuff if it is in the name. -- _____________________________________ ---This space for rent--- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Patrick Shanahan wrote on 2014-10-04 16:45 (UTC-0400):

and I *always* lowercase photo filenames.

100% lower case letters? I don't like the way listings sort CAPS first either, but always here only applies to first letters. I commonly uppercase apparent syllable first letters. What I always do is remove underscores. I hate the work involved in typing them, seeing/reading them, and speaking them. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/3/2014 2:18 PM, Carlos E. R. wrote:

On 2014-10-03 22:14, Istvan Gabor wrote:

...

So if I do the copying the way I described above, after the time shift the file still has the correct local time time-stamp. But if I mount the card after the time shift the time-stamp will be shifted. That is the time-stamps will differ only because the files were copied at different times (ie the filesystems were mounted at different times). I consider this a buggy behavior. The time stamp should always be the same for the same file and shouldn't depend on when the filesystem is mounted.

But... FAT does not store times in UTC, but in local time. The local time valid at the time each file is written. And it does not save the timezone info anywhere.

So, say you save a file at 3:00 in winter. When you mount it any other time on any part of the world, any time zone, any time of the year, in an msdos system, it will still say 3:00.

Times in FAT are relative.

That's the problem I told you on my first post. It is unsolvable. It is not buggy, it is simply limited (bad) initial design.

You are right, of course. http://msdn.microsoft.com/en-us/library/windows/desktop/ms724290(v=vs.85).as... On an NTFS file system there is more capability, but most portable devices are saddled with this stupid FAT system, which is about the dumbest decision ever made. - -- _____________________________________ - ---This space for rent--- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAlQvFFkACgkQv7M3G5+2DLKXOACfaadnPY+jQfjSJV9JJL+Hru/u ZZUAnj1sJKeFnW1D6Jp1c0Gi701VllIp =fnI9 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/10/14 22:25, John Andersen wrote:

You are right, of course. http://msdn.microsoft.com/en-us/library/windows/desktop/ms724290(v=vs.85).as...

On an NTFS file system there is more capability, but most portable devices are saddled with

this stupid FAT system, which is about the dumbest decision ever made.

TomTom would agree with you: https://en.wikipedia.org/wiki/Microsoft_Corp._v._TomTom_Inc. :-( - -- Bob Williams System: Linux 3.11.10-21-desktop Distro: openSUSE 13.1 (x86_64) with KDE Development Platform: 4.14.1 Uptime: 06:00am up 2 days 19:12, 4 users, load average: 0.24, 0.48, 0.32 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlQvHoQACgkQ0Sr7eZJrmU4JwwCgpFVtcpwba2ln+iionaAZzh2y gI4AnjJhPs2YIF22jQG/yu+XRIBAZkD1 =vtwj -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/10/14 23:16, Carlos E. R. wrote:

On 2014-10-04 00:09, Bob Williams wrote:

...

On 03/10/14 22:25, John Andersen wrote:

...

On an NTFS file system there is more capability, but most portable devices are saddled with

...

this stupid FAT system, which is about the dumbest decision ever made.

TomTom would agree with you:

https://en.wikipedia.org/wiki/Microsoft_Corp._v._TomTom_Inc.

:-(

The daft party here was TomTom, for choosing FAT for a Linux machine.

Yes, indeed. - -- Bob Williams System: Linux 3.11.10-21-desktop Distro: openSUSE 13.1 (x86_64) with KDE Development Platform: 4.14.1 Uptime: 06:00am up 3 days 19:12, 3 users, load average: 0.00, 0.01, 0.05 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlQv1UcACgkQ0Sr7eZJrmU6biACfaaRqF44TosB/5XajrpW1Cvdm /ugAnj71v9/4muKjjZEpzG2e7r5ZjMZi =FHlS -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Dear All: "Carlos E. R." írta:

On 2014-10-03 22:14, Istvan Gabor wrote:

...

So if I do the copying the way I described above, after the time shift the file still has the correct local time time-stamp. But if I mount the card after the time shift the time-stamp will be shifted. That is the time-stamps will differ only because the files were copied at different times (ie the filesystems were mounted at different times). I consider this a buggy behavior. The time stamp should always be the same for the same file and shouldn't depend on when the filesystem is mounted.

But... FAT does not store times in UTC, but in local time. The local time valid at the time each file is written. And it does not save the timezone info anywhere.

Yes. It works like that. I do understand this.

So, say you save a file at 3:00 in winter. When you mount it any other time on any part of the world, any time zone, any time of the year, in an msdos system, it will still say 3:00.

Yes, and linux should do the same. That is take that time stamp _literally_ and apply it in the current local time. But linux is "clever": it checks the timestamp of the file on the vfat partition. If that timestamp reflects a time which is in a different daylight saving time period than the computer uses currently, it applies a shift to the time stamp. To make it clear by example: I take a photo in January, the time stamp for the file is in January on the vfat filesystem. I mount the card in June on my computer, which in June uses summer time daylight shift. The computer finds out that the photo was taken in winter and applies a one hour time shift. That is a mistake. The time stamp should not be adjusted in any way it just should be represented as is. For example how the computer knows the dates when the daylight saving have to be applied? It differs in different countries. And not all country uses daylight saving times. As I feel that this thread was a little bit hijacked or at least biased, let me emphasize what I concluded: 1. This problem has nothing to do with preserving time stamps (be it creation time or last modification time) during files copies. 2. This problem is not a time zone problem. The time zone problem is handled by the tz=UTC mount option. 3. This problem is a linux mount or kernel problem: mount applies a time shift; this time shift should not be done. 4. For photos or other files which have time stamps in their metadata (eg exif info), applying that time stamp to the file's last modification (or creation) time is a usable workaround.

What would you think is the most expedient way to get beyond this issue? File bug reports and hold off doing anything till these are handled?

In my case, when I want to preserve the original time stamps of photos, I guess I will use the exiv2 command as John suggested. If I knew who is the developer responsible for linux mount I might write him personal email regarding the issue. Thank you all for your responses. Istvan -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R. wrote on 2014-10-04 17:58 (UTC+0200):

Istvan Gabor wrote:

...

...

So, say you save a file at 3:00 in winter. When you mount it any other time on any part of the world, any time zone, any time of the year, in an msdos system, it will still say 3:00.

...

Yes, and linux should do the same.

No, Linux is not Windows.

Not everything Windows does is wrong. Not everything Linux does is right. Regardless of OS, if during the seconds before and after a seasonal change takes place one is staring at a file's timestamp in a file manager that auto-refreshes as directory content changes, one should not see it change. Nothing happened to the file on account of time any more than it happened to a desk or a book, simply getting older less than a attosecond at a time. Poor as FAT is as a filesystem, it is what it is. A timestamp from a FAT filesystem should not be evaluated or interpreted, just reported. It is what *it* is. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R. wrote on 2014-10-05 14:38 (UTC+0200):

Felix Miata wrote:

...

Poor as FAT is as a filesystem, it is what it is. A timestamp from a FAT filesystem should not be evaluated or interpreted, just reported. It is what *it* is.

No, it is not. FAT timestamps are relative and have to be interpreted in Linux.

Relative to what? FAT only saves local time, nothing about UTC offset. AFAICT, any "interpretation" can be no more than speculation about what the offset might have been when the file was put onto the filesystem, or some earlier date on another filesystem where it could have been copied to FAT from. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R. wrote on 2014-10-08 12:59 (UTC+0200):

Felix Miata wrote:

...

Carlos E. R. wrote on 2014-10-05 14:38 (UTC+0200):

...

...

Felix Miata wrote:

...

...

...

Poor as FAT is as a filesystem, it is what it is. A timestamp from a FAT filesystem should not be evaluated or interpreted, just reported. It is what *it* is.

...

...

No, it is not. FAT timestamps are relative and have to be interpreted in Linux.

...

Relative to what? FAT only saves local time, nothing about UTC offset. AFAICT, any "interpretation" can be no more than speculation about what the offset might have been when the file was put onto the filesystem, or some earlier date on another filesystem where it could have been copied to FAT from.

Exactly. It is an "estimate" or "educated guess".

Hence, do *not* "have to be interpreted", and have nothing relevant to be relative to except themselves. Whatever the FAT filesystem reports, is what there is. It is what *it* is. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

jdd wrote on 2014-10-08 20:11 (UTC+0200):

Felix Miata composed:

...

Hence, do *not* "have to be interpreted", and have nothing relevant to be relative to except themselves. Whatever the FAT filesystem reports, is what there is. It is what *it* is.

one of the first thing I learned in data processionf is that computer do what you ask them to do, not what you expect them to do :-)

What is "asked" is often implied by a configuration file, not explicit. So sometimes it is the person who created the config file whose expectation is different from the user, not the "computer". -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2014-10-03 21:09, Istvan Gabor wrote:

"Carlos E. R." <> írta:

But I have a question:

If I take a photo now and mount the card right after it (practically within the same daylight shift period) the time stamp reflects the current local time correctly (as expected). If I leave this file on the hard drive and wait for a few weeks or months until the daylight shift period has changed (for example from summer time to winter time) will the time stamp of this file be changed (shifted by an hour) on my hard drive (ext3 filesystem)?

No, I believe not. However... the same file can simultaneously list different timestamps for different users that have different locales, on the same machine and session. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 2014-10-03 18:46, John Andersen wrote:

Can't you just use the image name as an indicator of date? Most cameras these days use date as part of the name.

If not, with a camera I had I wrote a script to rename the files according to the date.

In any event the date and time are encoded in the exif information anyway.

Relying on the date to remain reliable for the life of the photo is going to be problematic even if you do get it to work for the initial copy.

Absolutely. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

Le 03/10/2014 21:14, Istvan Gabor a écrit :

Absolutely not. If I write the files onto DVD they time stamps won't change anymore. They only change when I mount the filesystem before writing the DVD.

many copy utility changes the time stamp, for example if you copy from the camera (not from the sd card) a file may be copied to or from many suports in his life, file date is not reliable jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

jdd írta:

Le 03/10/2014 21:14, Istvan Gabor a écrit :

...

Absolutely not. If I write the files onto DVD they time stamps won't change anymore. They only change when I mount the filesystem before writing the DVD.

many copy utility changes the time stamp, for example if you copy from the camera (not from the sd card)

Those are the copy utilities I don't use. Those which I use preserve time stamps (creation time).

a file may be copied to or from many suports in his life, file date is not reliable

I think the opposite. It is reliable provided it is handled correctly by the OS. Furthermore, please read my previous post, where I explain why your argument is not valid in my case. Istvan -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2014-10-03 22:03, Istvan Gabor wrote:

jdd írta:

...

many copy utility changes the time stamp, for example if you copy from the camera (not from the sd card)

Those are the copy utilities I don't use. Those which I use preserve time stamps (creation time).

Are you sure? Look: cer@Telcontar:~/tmp/date> l /home/cer-g/.xinitrc.template -rwxr-xr-x 1 cer-g users 1112 May 14 04:12 /home/cer-g/.xinitrc.template* cer@Telcontar:~/tmp/date> cp /home/cer-g/.xinitrc.template . cer@Telcontar:~/tmp/date> l .xinitrc.template -rwxr-xr-x 1 cer users 1112 Oct 3 23:39 .xinitrc.template* cer@Telcontar:~/tmp/date> QED. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 2014-10-04 00:13, John Andersen wrote:

On 10/3/2014 2:41 PM, Carlos E. R. wrote:

But done with mv instead of cp the time stamp stays the same. (At least on same filesystem). I'm too lazy to find a fat device to test with.

He. I'd never move an important file, such as photos. First I copy them, to two destinations, then I verify them, and only then I risk deleting the original. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 2014-10-04 07:36, Felix Miata wrote:

Carlos E. R. wrote on 2014-10-03 23:41 (UTC+0200):

...

Istvan Gabor wrote:

...

...

jdd wrote:

...

...

...

many copy utility changes the time stamp, for example if you copy from the camera (not from the sd card)

...

...

Those are the copy utilities I don't use. Those which I use preserve time stamps (creation time).

...

Are you sure? Look:

...

cer@Telcontar:~/tmp/date> l /home/cer-g/.xinitrc.template -rwxr-xr-x 1 cer-g users 1112 May 14 04:12 /home/cer-g/.xinitrc.template* cer@Telcontar:~/tmp/date> cp /home/cer-g/.xinitrc.template . cer@Telcontar:~/tmp/date> l .xinitrc.template -rwxr-xr-x 1 cer users 1112 Oct 3 23:39 .xinitrc.template* cer@Telcontar:~/tmp/date>

It's not clear to me what the above is supposed to demonstrate. Why would any file be given a name that includes a wildcard character (.xinitrc.template*), if even legal?

Wow. Please, take another cup of coffee, relax, and look again :-) That asterisk is displayed by "ls" and means the file is executable. It is not part of the name. What you were supposed to look at were the dates of the origin of the copy and the destination. Besides that, of course that you can name a file with an asterisk in it - why not? :-p See: cer@Telcontar:~/tmp/date> touch pepe\* cer@Telcontar:~/tmp/date> l total 8 drwxr-xr-x 2 cer users 18 Oct 4 13:40 ./ drwxr-xr-x 74 cer users 4096 Oct 4 13:40 ../ -rw-r--r-- 1 cer users 0 Oct 4 13:40 pepe* cer@Telcontar:~/tmp/date> cer@Telcontar:~/tmp/date> rm pepe\* cer@Telcontar:~/tmp/date

Most of my individual and small group copying is done in an OFM. e.g. mc's <F5> (aka copy) apparently is configured by default on <F5> to preserve all attributes, including timestamp. It's what I expect every time I copy any normal file anywhere, regardless of copying tool used. To me, after decades of DOS and OS/2 use where such is the normal case, copying any regular file is equivalent to cloning it, making an exact duplicate. I find it inexplicable that gnu cp does not preserve all attributes by default, and little less difficult to comprehend how hard it can be in any exercise to make attribute preservation happen.

Linux is not Windows :-) Meaning, Linux is under no obligation to mimic MsDos/Windows behaviour, even less on the traditional CLI, which may predate MsDOS. Another huge but subtle difference is how the shell treats wildcards. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 2014-10-05 07:57, Felix Miata wrote:

Carlos E. R. wrote on 2014-10-04 13:46 (UTC+0200):

...

That asterisk is displayed by "ls" and means the file is executable. It is not part of the name.

What "ls"?

$ l If 'l' is not a typo you can use command-not-found to lookup the package that contains it, like this: cnf l $

Thus, I don't know what command you issued.

How many years have you been using *suse? ;-) It is a traditional "suseism". cer@Telcontar:~> alias | grep ls alias dir='ls -l' alias l='ls -alF' <============ alias la='ls -la' alias ll='ls -l' alias ls='_ls' alias ls-l='ls -l' alias unmount='echo "Error: Try the command: umount" 1>&2; false' alias you='if test "$EUID" = 0 ; then /sbin/yast2 online_update ; else su - -c "/sbin/yast2 online_update" ; fi' cer@Telcontar:~> cer@Telcontar:~> l .alias -rw-r--r-- 1 cer users 116 Jul 3 2006 .alias cer@Telcontar:~> I did not put it there.

...

What you were supposed to look at were the dates of the origin of the copy and the destination.

Obviously, but the context registering in my brain was incomplete for failure to understand the presence of the trailing asterisk.

You could have guessed. Humans are known to be able to compute properly with missing information. Computers do not ;-p -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 2014-10-08 08:51, Felix Miata wrote:

...

cer@Telcontar:~> l .alias -rw-r--r-- 1 cer users 116 Jul 3 2006 .alias cer@Telcontar:~>

...

I did not put it there.

So I see, but I can't recall ever finding one around here. All my own aliases come from .bashrc. Can you find out where .alias came or comes from? Maybe it's a bug only on en_US systems to not have one, or a feature of selected locales?

I don't know... I looked at /etc/skeleton, it is not there. Maybe from an older release. I'd have to look at them in vmware installs. [...] On 5.3 the alias is working, but it is not in the .alias file. There is no .bashrc either (I'm looking at root's). Ah, got it, from /etc/profile. I can't copy here the definition, I haven't managed to start sshd server on it. Ah, got it: telnet. # Further options for the 'ls' command are in /etc/DIR_COLORS. alias ls='ls --color=tty' alias dir='ls -l' alias ll='ls -l' alias la='ls -la' alias l='ls -alF' alias ls-l='ls -l' alias o='less' alias ..='cd ..' alias ...='cd ../..' alias +='pushd .' if [ -z "$KSH_VERSION" ]; then alias -- -='popd' fi alias rd=rmdir alias md='mkdir -p' alias unix2dos='recode lat1:ibmpc' alias dos2unix='recode ibmpc:lat1' alias unzip='unzip -L' alias which='type -p' In 11.4 I don't see where it comes. There is /etc/profile and /etc/profile.d/, but I don't locate the definition. Ah! Got it: /etc/profile.d/ls.bash Same in 13.1. Definition is: alias dir='ls -l' alias ll='ls -l' alias la='ls -la' alias l='ls -alF' alias ls-l='ls -l' Telcontar:~ # rpm -qf /etc/profile.d/ls.bash aaa_base-extras-13.1-16.46.1.x86_64 :-)) -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

Carlos E. R. wrote on 2014-10-08 12:05 (UTC+0200):

In 11.4 I don't see where it comes. There is /etc/profile and /etc/profile.d/, but I don't locate the definition. Ah! Got it:

/etc/profile.d/ls.bash

No such file on this 11.4 installation.

Same in 13.1. Definition is:

alias dir='ls -l' alias ll='ls -l' alias la='ls -la' alias l='ls -alF' alias ls-l='ls -l'

# rpm -qf /etc/profile.d/ls.bash aaa_base-extras-13.1-16.46.1.x86_64

I booted a random 13.1 installation, and this is installed. However, I wouldn't count on it necessarily being installed on all my, or other's, openSUSE installations, as most start out as minimal so that I can set solver.onlyRequires = true in zypp.conf before fleshing out the installation. aaa_base-extras exists for 11.4, but is not here installed. IOW, when pasting command output in list mail, it cannot be clear to all who might be reading your post what it is that you are doing when using any alias. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Patrick Shanahan wrote on 2014-10-08 14:28 (UTC-0400):

Felix Miata composed:

...

Carlos E. R. wrote on 2014-10-08 12:05 (UTC+0200):

...

...

In 11.4 I don't see where it comes. There is /etc/profile and /etc/profile.d/, but I don't locate the definition. Ah! Got it:

...

...

/etc/profile.d/ls.bash

...

No such file on this 11.4 installation.

rpm -qf /etc/profile.d/ls.bash aaa_base-extras-13.2+git20140911.61c1681-1.2.x86_64

Given the context of the entire post you replied do, not just what you quoted, what is this information supposed to be offering the reader of your reply, that Factory has not deleted ls.bash from, or dropped, the aaa_base-extras package post-13.1? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Most of my individual and small group copying is done in an OFM. e.g. mc's <F5> (aka copy) apparently is configured by default on <F5> to preserve all attributes, including timestamp. It's what I expect every time I copy any normal file anywhere, regardless of copying tool used. To me, after decades of DOS and OS/2 use where such is the normal case, copying any regular file is equivalent to cloning it, making an exact duplicate. I find it inexplicable that gnu cp does not preserve all attributes by default, and little less difficult to comprehend how hard it can be in any exercise to make attribute preservation happen.

All, I haven't followed this thread, but I'm pretty knowledgeable about timestamps. Ie. Knowing how they work is core to my job function - computer forensics. Ntfs and Windows is my typical professional need, so I'm fuzzier with Linux. Feel free to ask questions. Felix, You may expect tools to preserve timestamps in general, but I can assure most modern copy tools don't. If you restrict yourself to the last modified datestamp, then you are closer to right. For Windows the "create" date is the date that a specific file was created on the current filesystem. Thus moving a file within a filesystem doesn't update the create date. Copying it to a thumb drive sets the create time to the current time. That is a feature of the Windows kernel. Tools like "cp --archive" have to override the default behavior by making calls to the kernel after the copy to reset the timestamps. All, NTFS is very cool in the way it handles timestamps. It maintains 2 sets of timestamps inside the filesystem metadata. One is primary and tools like "cp --archive" can adjust them via a Windows api after the fact to work as the tool designer wants them to. The other set is rarely used, but rigidly does what the Windows kernel wants. No api is provided to change them. Thus if a tarball (or zip file) is extracted in Windows with the restore timestamps option, the visible timestamps get reset to the original values, but the hidden set still have the time of the extraction. Having that hidden set can be helpful when working with malware that tries to hide by backdating itself. Fyi: I'm not familiar with any typical end-user tools that give access to the second set of timestamps. There are forensic tools that I use that do. A couple of those are in the opensuse distro. See analyzemft as an example. Greg -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Greg Freemyer wrote on 2014-10-04 09:07 (UTC-0400):

...

...I find it inexplicable that gnu cp does not preserve all attributes by default, and little less difficult to comprehend how hard it can be in any exercise to make attribute preservation happen.

All,

I haven't followed this thread, but I'm pretty knowledgeable about timestamps. Ie. Knowing how they work is core to my job function - computer forensics. Ntfs and Windows is my typical professional need, so I'm fuzzier with Linux. Feel free to ask questions.

Felix,

You may expect tools to preserve timestamps in general, but I can assure most modern copy tools don't.

One of the reasons why I stick to OFMs as much as practical.

If you restrict yourself to the last modified datestamp, then you are closer to right.

:-)

For Windows the "create" date is the date that a specific file was created on the current filesystem. Thus moving a file within a filesystem doesn't update the create date. Copying it to a thumb drive sets the create time to the current time.

Proof I wasn't imagining differences according to context in the Win9x days, continuing with HPFS, and another reason for sticking with OFMs. :-p

That is a feature of the Windows kernel. Tools like "cp --archive" have to override the default behavior by making calls to the kernel after the copy to reset the timestamps.

All,

NTFS is very cool in the way it handles timestamps. It maintains 2 sets of timestamps inside the filesystem metadata.

One is primary and tools like "cp --archive" can adjust them via a Windows api after the fact to work as the tool designer wants them to.

The other set is rarely used, but rigidly does what the Windows kernel wants. No api is provided to change them. Thus if a tarball (or zip file) is extracted in Windows with the restore timestamps option, the visible timestamps get reset to the original values, but the hidden set still have the time of the extraction.

True for NTFS even when mounted and extracted using Linux?

Having that hidden set can be helpful when working with malware that tries to hide by backdating itself.

This good reason I hadn't considered. Outside of it and the work you do, are there others?

Fyi: I'm not familiar with any typical end-user tools that give access to the second set of timestamps. There are forensic tools that I use that do. A couple of those are in the opensuse distro. See analyzemft as an example. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation)

Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2014-10-05 12:11, Greg Freemyer wrote:

I don't know why NTFS has these timestamps.

Intentional design, I'd suppose, for things like I guess you do. To be able to track dates when they know that the users change them. Microsoft is not that daft as we say they are :-)

Google $standard_information (or $SI) and $file_name (or $FN) if you want to research it.

Here's a program I wish didn't exist:

https://github.com/jschicht/SetMace

Why? Guessing, it changes that internal timestamp? (I did not look) -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

Le 05/10/2014 15:33, Greg Freemyer a écrit :

...

...

Here's a program I wish didn't exist:

https://github.com/jschicht/SetMace

Why? Guessing, it changes that internal timestamp? (I did not look)

Yes, it is touch on steroids for NTFS

really smart piece of software, no more lock possible for demo based on timestamp :-( and on the thread subject: "Timestamps are written as UTC and thus will show up in explorer as interpreted by your timezone location" so to stop any time stamp problem, a solution could be to set all devices (cameras...) on UTC and not local time jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2014-10-06 15:29, Greg Freemyer wrote:

For fat and vfat that is not a realistic option. There are billions of fat filesystems in existence that have the time recorded as local time. There is no way Windows and Linux can suddenly start defaulting to knowing that users are now using GMT on fat.

Nor cameras. They store proper timestamps inside, in exif. It would break. Or not, I think the timezone is also stored. I'd have to check. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlQyxuoACgkQja8UbcUWM1x9ZgD9HD/bJ2eG5+6gxtQ1jSH96X5O FTeuPMBKPViRngey3OUA/jzu5IytQalunSi/TJVl2RkcIBHnL5RNpoIdEV9NSVPJ =HWDd -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

* Patrick Shanahan [10-03-14 14:46]:

* Istvan Gabor [10-03-14 12:21]:

...

I have an sdcard used in a digital camera. Photos were taken in February. I want to copy the files from there to my openSUSE 12.2 desktop computer. I also want the files to have local time stamps corresponding to the original time stamp on the vfat filesystem. For example if the picture was taken (according to creation time in the file's metainfo) at 10:30, I want 10:30 to be the file's time stamp after mounting the sdcard. Currently the file's time stamp is 09:30 if I don't use tz option for the mount command. If I use tz=UTC option the file's time stamp is 11:30. Neither of these is correct. I tried yo use other values for tz, utz=CET, tz=UTC+1 etc but they were not accepted. It is really important to have the correct time stamps, so how can I?

your chosen email client does *not* wrap lines :^(

exiv2 -T ./*.{nef,jpg}

Note that this changes the file time-stamp to match the exif creation date and does not make any automagick adjustments. If the date in your camera is correct, the file time-stamp will be correct. If you change time zones or from/to daylight saving time and do not *manually* change the camera setting, the files will contain incorrect exif data. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Exiv2 also has an argument "mv" which will rename the file to match the exif time stamp, and add customization, if you are merging pictures from two or more cameras which just happened to have name collisions. On October 3, 2014 11:49:11 AM PDT, Patrick Shanahan wrote:

...

* Istvan Gabor [10-03-14 12:21]:

...

I have an sdcard used in a digital camera. Photos were taken in February. I want to copy the files from there to my openSUSE 12.2 desktop computer. I also want the files to have local time stamps corresponding to

...

...

original time stamp on the vfat filesystem. For example if the picture was taken (according to creation time in

...

...

file's metainfo) at 10:30, I want 10:30 to be the file's time stamp after mounting the sdcard. Currently the file's time stamp is 09:30 if I don't use tz option for the mount command. If I use tz=UTC

* Patrick Shanahan [10-03-14 14:46]: the the option the

...

...

file's time stamp is 11:30. Neither of these is correct. I tried yo use other values for tz, utz=CET, tz=UTC+1 etc but they were not accepted. It is really important to have the correct time stamps, so how can I?

your chosen email client does *not* wrap lines :^(

exiv2 -T ./*.{nef,jpg}

Note that this changes the file time-stamp to match the exif creation date and does not make any automagick adjustments. If the date in your camera is correct, the file time-stamp will be correct. If you change time zones or from/to daylight saving time and do not *manually* change the camera setting, the files will contain incorrect exif data.

-- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

* Istvan Gabor [10-03-14 16:36]: [...]

Of course if the camera clock is set incorrect both the exif time and file time stamp (the original one, not linux mounted) will be incorrect. But this has not to do anything with my problem.

I seem to recall windoz sets the file date to the last modification date in that particular directory. So moving/copying a file from one location to another, even renaming, alters the file time-stamp. Short of installing cygwin and using a script to touch the new file with the original's time-stamp, I believe you are positioned in that proverbial river without proper propelling equipment. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2014-10-03 23:20, John Andersen wrote:

On 10/3/2014 1:52 PM, Patrick Shanahan wrote:

...

I seem to recall windoz sets the file date to the last modification date in that particular directory. So moving/copying a file from one location to another, even renaming, alters the file time-stamp.

Right. Even Linux can do that, depends.

Windows has both times (created and modified) available. (NTFS).

But cameras use FAT. Or exFAT some of them. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

Patrick Shanahan wrote on 2014-10-03 16:52 (UTC-0400):

Istvan Gabor wrote:

...

Of course if the camera clock is set incorrect both the exif time and file time stamp (the original one, not linux mounted) will be incorrect. But this has not to do anything with my problem.

I seem to recall windoz sets the file date to the last modification date in that particular directory. So moving/copying a file from one location to another, even renaming, alters the file time-stamp.

I don't remember anything like that. Maybe rather than "windoz" you mean Windows Explorer in DND mode? I used DOS and OS/2 many years before first use of Explorer, and as an OFM user, never really did use it much if I had an OFM option readily available. I really can't put my recollection on any instances of copying regular files where timestamps were not automatically preserved with DOS COPY, Norton Commander, FC/2, or newer OFMs for win95 & up. In fact, on FAT and HPFS, I was in the habit of using OFMs to change directory timestamps to match each other so that DIR listings would always show directories in alphabetical order even though files would be shown in order of whichever of time or alpha sort was being applied. I do have a problem with the notion that both creation and last modified both exist as distinct "regular" file attributes. Where at filesystem level can relevance lie for preserving creation when last modified is newer? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2014-10-04 10:05, John Andersen wrote:

On 10/3/2014 10:36 PM, Felix Miata wrote:

...

I do have a problem with the notion that both creation and last modified both exist as distinct "regular" file attributes. Where at filesystem level can relevance lie for preserving creation when last modified is newer?

Wait, What? This whole thread has been about wanting the preserve the date that photos were taken via the file-system date. Now you question the usefulness of that?

The fact that 'nix systems have always preserved both dates and Microsoft felt compelled to add it in NTFS as well as exFAT should suggest this isn't the only reason for doing so.

In fact, Linux filesystems store *three* different timestamps. Vfat keeps one. Other, more recent, Windows filesystems, keep two, creation and last modification, because it simply is useful. cer@Telcontar:~> stat p File: ‘p’ Size: 109 Blocks: 8 IO Block: 4096 regular file Device: 10301h/66305d Inode: 134977 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ cer) Gid: ( 100/ users) Access: 2014-10-02 23:19:09.904084937 +0200 Modify: 2014-07-14 05:10:37.000000000 +0200 Change: 2014-10-01 17:28:38.886944560 +0200 Birth: - cer@Telcontar:~> Notice that it is not creation date, but modification date. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 2014-10-04 22:29, John Andersen wrote:

On 10/4/2014 4:53 AM, Carlos E. R. wrote:

...

Modify: 2014-07-14 05:10:37.000000000 +0200 Change: 2014-10-01 17:28:38.886944560 +0200

Change only refers to the date of permissions change (metadata).

I did not change the permissions of that file. I copied it, though, with rsync, as root, or mc, which possibly implies a permission change from root to me. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)