How to preserve times when copying images from smartmobile usb memory to Linux disk

English Applications
1

Using openSUSE 13.2, kernel 3.16.7 x86_64 and Gnome 3.14.4 desktop. When connecting my Samsung S4 smartmobile using a usb connection, the default behavior “Open with Files” launches mtp://[usb:001,003]/ in Nautilus.

Going down to mtp://[usb:001,003]/Card/DCIM/Camera loads (lists) all image files on the usb memory.
Copy image files and Paste into another Nautilus tab disk folder works, but the original image times are not preserved during copying and changes to the current operation time.

Is there any method to preserve times using the default Nautilus (gui) for this ‘Copy & Paste’ job?

A related problem is that the smartmobile usb memory is not listed among mounts using the command line “df -h”.
In comparision, my external usb backup disk is shown when connected, and it is possible to use the command line tools “rsync” or “cp -p” to preserve file stamps during copying.

How to possibly find the mount point for the usb memory so that the command line tools can be used?

2

AFAIK, no.
So unless someone suggests something I’m not aware of…

This is because Nautilus is a file manager, so does operations at the file level.
When you copy something, you’re creating a brand new instance of the original file, so the new file will be timestamped with the new time.

But, if you did a file copy operation at the disk block level (like using the command line dd) then the timestamps would be preserved.

A common workaround I’ve seen for your scenario is to name the file based on the date.

TSU

3

A rather hidden question at the end of this story :wink:

You can find what is mounted where with

mount

You can reduce the amount of output by filtering on the mounts that use mass-storage devices (in /dev):

mount | grep '/dev'
4

Hi
What about go-go-mtpfs and there is mtp-tools. There is also mptfs at https://build.opensuse.org/package/show?project=home%3Alrupp&package=mtpfs

5

On 2015-06-18 22:46, tsu2 wrote:

> This is because Nautilus is a file manager, so does operations at the
> file level.
> When you copy something, you’re creating a brand new instance of the
> original file, so the new file will be timestamped with the new time.

‘mc’ /preserves/ the timestamps. What it does is that first it creates
the new file, then it modifies the timestamps. This is an optional
behaviour.

> A common workaround I’ve seen for your scenario is to name the file
> based on the date.

Or use exif data.

–
Cheers / Saludos,

Carlos E. R.

(from 13.1 x86_64 “Bottle” (Minas Tirith))

6

On 2015-06-18 16:06, terjejh wrote:

> How to possibly find the mount point for the usb memory so that the
> command line tools can be used?

Impossible. When using the “mtp” protocol, there is no actual mount.
Nautilus fakes it.

–
Cheers / Saludos,

Carlos E. R.

(from 13.1 x86_64 “Bottle” (Minas Tirith))

7

When they are JPEG files that might be a solution for you. Use

jhead -ft *.jpg

(or any other suitable expression for *.jpg in your situation)
For more information of course

man jhead

I do not know if jhead is installed by default. Else instal it e.g.

su -c 'zypper in jhead'
8

Manipulating exif data directly and indirectly using something like jhead only modifies the image file metadata, the regular file properties remain as I described.
Unless you use an image viewing app, ordinarily this metadata isn’t visible although it can contain a lot of useful information.

It generally shouldn’t be visible in a regular file manager unless the file manager has extensions to read the metadata (some/many do).

TSU

9

jhead does not “only” work on work on the internal meta data. It can also set the files date/time in the file system. And that is what the -ft does. It reads the date the picture was made from the meta data (called Exif in the case of JPEG) and then uses an equivalent of touch -d to set the date/time in the file system accordinly. This will most probably restore the original date/time of the file as it was on the camera.

10

terjejh;
You might take a look at package Digikam, an open source photo management program.
It loads by default on a KDE system, I’m not sure about Gnome.

Of the zillions of things it does, it allows you to rename files based on exif metadata.

You might find all of digikam useful, or you might find a way to use the file renamer.

You might also have a look at exiftool

11

Weird. With my phone connected by USB to a oS 13.2 64-bit KDE 1.14 desktop, I can copy a file from the phone storage (internal or SD) to the desktop in Dolphin and the file date/time is preserved. Same if I use copy by wireless with kdeconnect (using dolphin from the desktop or sending the file from the phone).

Maybe a gnome issue? But it seems improbable. I remember having this problem many years ago, with KDE3, but never since.

Possibly a good search - including this very same fora - will help.

12

On 2015-06-20 07:46, brunomcl wrote:

> Maybe a gnome issue? But it seems improbable. I remember having this
> problem many years ago, with KDE3, but never since.

No, it is a file browser issue.

As others have said, copying a file creates in fact a new file, belonging to the user running the browser, and time-stamped that instant.

Some file browsers later change the time stamp to the original. Some, like ‘mc’, have that as optional.

So it seems that nautilus doesn’t preserve the time stamp, and dolphin does. This is nice to know :slight_smile:

I was going to try “thunar”, but today my tablet chooses not to connect. Neither nautilus nor dolphin works today.

<0.6> 2015-06-20 13:43:59 Telcontar kernel - - - [311557.664262] usb 1-2.1: new high-speed USB device number 17 using ehci-pci
<0.6> 2015-06-20 13:43:59 Telcontar kernel - - - [311557.742387] usb 1-2.1: New USB device found, idVendor=8087, idProduct=0a15
<0.6> 2015-06-20 13:43:59 Telcontar kernel - - - [311557.742390] usb 1-2.1: New USB device strings: Mfr=2, Product=3, SerialNumber=4
<0.6> 2015-06-20 13:43:59 Telcontar kernel - - - [311557.742392] usb 1-2.1: Product: Android
<0.6> 2015-06-20 13:43:59 Telcontar kernel - - - [311557.742394] usb 1-2.1: Manufacturer: Android
<0.6> 2015-06-20 13:43:59 Telcontar kernel - - - [311557.742396] usb 1-2.1: SerialNumber: L…
<1.6> 2015-06-20 13:43:59 Telcontar mtp-probe - - - checking bus 1, device 17: “/sys/devices/pci0000:00/0000:00:1a.7/usb1/1-2/1-2.1”
<1.6> 2015-06-20 13:43:59 Telcontar mtp-probe - - - bus: 1, device: 17 was not an MTP device

The issue is “was not an MTP device”, so it does not appear… I’ll try later on my laptop, see if there is a difference.

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

13

On 2015-06-20 13:55, Carlos E. R. wrote:

> The issue is “was not an MTP device”, so it does not appear… I’ll try later on my laptop, see if there is a difference.

The laptop connected instantly. Thunar “changes” the date.

–
Cheers / Saludos,

Carlos E. R.

(from 13.1 x86_64 “Bottle” (Minas Tirith))

14

Nice discussion, but it seems that we lost the OP somewhere >:(

15

I remember how infuriated I was almost a decade ago, after I copied pictures from different cameras - with different file naming conventions, most still in the 8.3 format, and couldn’t order by date because they were all the same. At first I thought it was a bug or setting, as I could do this since forever in windows 95/98/ME/XP, but then someone told me it was by design, live with it. Stupid design.

Obviously a copy is another file, but why does it have to change file attributes that are not required, like ownership? From the ordinary user perspective there’s no logic to this.

Or perhaps it’s a “you don’t need it because it may confuse you” developer mindset (a famous DE comes to mind…).>:)

Thank heavens for the sensible KDE developers, that don’t treat me as a dumb newbie.

16

You can not say at one moment: it is a new file and at the next moment: why does it change ownership.

It is a new file, thus at creation it gets new filename, new timestamps, ownership (user and group) as per the user that created it, permissions as per the bits suggested by the creator program masked with umask. Nothing is changed there, because there was nothing.

Very basic Unix/Linux since 40+ years.

17

Hi,

A work around if a GUI program does not preserve time during a transfer is to use

touch

and

date

utility and probably

stat

Contrary to popular belief touch main purpose is not to create empty files :wink:

touch --help

will probably suffice if you’re looking for some info.

18

On Sat 20 Jun 2015 04:46:01 PM CDT, brunomcl wrote:

Or perhaps is a “you don’t need it because it may confuse you” developer
mindset (a famous DE comes to mind…).>:)

Thank heavens for the sensible KDE developers, that don’t treat me as a
dumb newbie.

Hi
Hmmm if you say so :wink:

Now, with an iphone copying pictures via nautilus and using usbmux
timestamps are preserved…

I believe it’s a combination of android os (as it’s running as root…)
and/or fuse and usbfs (which is indicated on the web).

Tested a copy from an Fire via nautilus (the photo retains the img info
in the name) creates a new file and timestamp which I would guess is
because of an ownership changes…?

I need to wait for OBS to settle with gcc5 and install jmtpfs and see
how that goes with the fire and once the ASUS transformer is recharged
that…

–
Cheers Malcolm °¿° LFCS, SUSE Knowledge Partner (Linux Counter #276890)
SUSE Linux Enterprise Desktop 12 GNOME 3.10.1 Kernel
3.12.43-52.6-default If you find this post helpful and are logged into
the web interface, please show your appreciation and click on the star
below… Thanks!

19

On 2015-06-20 19:46, hcvv wrote:
> It is a new file, thus at creation it gets new filename, new timestamps,
> ownership (user and group) as per the user that created it, permissions
> as per the bits suggested by the creator program masked with umask.
> Nothing is changed there, because there was nothing.
>
> Very basic Unix/Linux since 40+ years.

“cp -a” keeps all attributes. It is just an optional, design behaviour.
Some designers choose do it one way, others choose another way. None is
a wrong way :slight_smile:

–
Cheers / Saludos,

Carlos E. R.

(from 13.1 x86_64 “Bottle” (Minas Tirith))

20

That is not completely true as you will understand when you understand permissions. And I think the understanding of what happens would be better if the word “preserve” wasn’t used casualy (also in man cp). It does not preserve, but it will (try to) set mode, ownership, timestamps to those of the original file after the new file is created.

And it can of course only do that when allowed to do so by having write access to the inodes of the directory (the x bit of the directory). Thus, for home work, take a piece of paper and write down all combinations of original owner, user doing the cp, owner of new directory, several permission bit combinations of those and calculate what the results will be in all those cases.

In fact cp -a is only realy usefull when either executed by one user on files owned by that user, or by root executed on files irrispective of the owner(s). In all other cases, it works of course ass documented, but might be difficult to understand by many.

YMMV.