I would like to copy a file
from srcdir [local HDD "UUID=5AAAA.. /mnt/srcdir ntfs-3g" in fstab]
to destdir [network share "//192.168.xx.xx /mnt/destdir ... cifs ..." in
fstab]
preserving the original creation date.
I've tried
> cp -p /mnt/srcdir/FILE.jpg /mnt/destdir/FILE.jpg
> rsync -vuart /mnt/srcdir /mnt/destdir
> dd ... can't remember the options
I've also tried with "freefilesync"
Unfortunately the timestamp on the destination is not preserved :-(
Is it there a way to
copy a file (many files) from local to network share
preserving timestamp ?
I'm considering "timeshift" but honestly ...
THANKS for any help

On 21/08/2024 16:25, ambaraba wrote:
> I would like to copy a file
> from srcdir [local HDD "UUID=5AAAA.. /mnt/srcdir  ntfs-3g" in fstab]
> to destdir [network share "//192.168.xx.xx /mnt/destdir ... cifs ..." in
> fstab]
> preserving the original creation date.
> I've tried
> > cp -p /mnt/srcdir/FILE.jpg /mnt/destdir/FILE.jpg
> > rsync -vuart /mnt/srcdir      /mnt/destdir
> > dd ... can't remember the options
> I've also tried with "freefilesync"
> Unfortunately the timestamp on the destination is not preserved :-(
> Is it there a way to
> copy a file (many files) from local to network share
> preserving timestamp ?
> I'm considering "timeshift" but honestly ...
> THANKS for any help

rsync copies my date info???

--
“when things get difficult you just have to lie”

― Jean Claud Jüncker

On Wed, 21 Aug 2024 17:25:52 +0200, ambaraba wrote:

> I would like to copy a file
> from srcdir [local HDD "UUID=5AAAA.. /mnt/srcdir ntfs-3g" in fstab]
> to destdir [network share "//192.168.xx.xx /mnt/destdir ... cifs ..."
> preserving the original creation date.

To summarize, you want to use Linux tools to copy a file from a (Windows)
NTFS directory to a (Windows-compatible) CIFS directory, preserving the
(Windows) "creation date" metadata.

While some Linux filesystems support "file creation date", most follow the
Unix metadata requirements and do not. Linux tools are very rarely built to
know about non-standard metadata, and don't adjust things like "creation
date". AFAIK, the Linux vfs (that mediates file accesses to the variety
of supported Linux filesystems) doesn't easily carry that metadata, nor
do the standard file metadata syscalls.

In all, you are looking for a very unique and very rare utility, and I
doubt that most general-purpose Unix or Linux file copy tools will satisfy
your need.

HTH
--
Lew Pitcher
"In Skills We Trust"

On 8/21/24 18:05, Lew Pitcher wrote:
> To summarize, you want to use Linux tools to copy a file from a (Windows)
> NTFS directory to a (Windows-compatible) CIFS directory, preserving the
> (Windows) "creation date" metadata.
....

> HTH

Oh yes this/you helped me a LOT.
Copying from a win machine with win utility (robocop, in my case, but
prob. there are more) solved my problem :-)
THANKS

On 8/21/24 11:25 AM, ambaraba wrote:
> I would like to copy a file
> from srcdir [local HDD "UUID=5AAAA.. /mnt/srcdir  ntfs-3g" in fstab]
> to destdir [network share "//192.168.xx.xx /mnt/destdir ... cifs ..." in
> fstab]
> preserving the original creation date.
> I've tried
> > cp -p /mnt/srcdir/FILE.jpg /mnt/destdir/FILE.jpg
> > rsync -vuart /mnt/srcdir      /mnt/destdir
> > dd ... can't remember the options
> I've also tried with "freefilesync"
> Unfortunately the timestamp on the destination is not preserved :-(
> Is it there a way to
> copy a file (many files) from local to network share
> preserving timestamp ?
> I'm considering "timeshift" but honestly ...
> THANKS for any help

"cp -p <whatever> <wherever>" ... preserves time and ownership.

The '-a' "archive" mode can do the same. Experiment
with where/when to add a trailing slash with that one.

I've heard "touch -r" can actually do the same, but
have never used it that way. Probably evokes 'cp -p'.

If using some computer language's libraries to copy
stuff you MAY have to do it in two or three steps -
ie "get time/owner data", "do the copy", "set the
dest file with the original info". I wrote a lot
of backup programs - that oft stored compressed
and/or encrypted copies - and you kinda HAD to
do it this way just to be sure. Not HARD, but a
couple extra steps nevertheless.

Mosty this stuff is much easier with Linux/Unix than
in Winders. TRY to interpret THOSE docs for the Win
'C' library routines :-)

On Wed, 21 Aug 2024 17:25:52 +0200, ambaraba wrote:

> I've tried
> > cp -p /mnt/srcdir/FILE.jpg /mnt/destdir/FILE.jpg
> > rsync -vuart /mnt/srcdir /mnt/destdir
> > dd ... can't remember the options
> I've also tried with "freefilesync"
> Unfortunately the timestamp on the destination is not preserved :-(

cp and rsync should work. You can verify this by trying your same commands
between local volumes.

The fact that the commands don’t work on the file server sounds like the
fault of the file server.

On Thu, 22 Aug 2024 05:32:04 -0000 (UTC), Lawrence D'Oliveiro
<ldo@nz.invalid> wrote in <va6igk$a1bk$1@dont-email.me>:

> On Wed, 21 Aug 2024 17:25:52 +0200, ambaraba wrote:
>
>> I've tried
>> > cp -p /mnt/srcdir/FILE.jpg /mnt/destdir/FILE.jpg rsync -vuart
>> > /mnt/srcdir /mnt/destdir dd ... can't remember the options
>> I've also tried with "freefilesync"
>> Unfortunately the timestamp on the destination is not preserved :-(
>
> cp and rsync should work. You can verify this by trying your same
> commands between local volumes.
>
> The fact that the commands don’t work on the file server sounds like the
> fault of the file server.

Or the file server protocol, or even the API available to cp(1).

The OP was about the "creation time", which is supported in
the Linux statx(2) call in the statx struct as
[...]
struct statx_timestamp stx_btime; /* Creation */
[...]

The ext4 filesystem supports this, and you can see it if you run
stat(1) on a file:
# stat /etc/fstab
File: /etc/fstab
Size: 1100 Blocks: 8 IO Block: 4096 regular file
Device: 10306h/66310d Inode: 7602178 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2024-08-21 22:00:01.907146964 -0700
Modify: 2024-07-23 20:59:27.235228009 -0700
Change: 2024-07-23 20:59:27.235228009 -0700
Birth: 2023-10-12 05:05:55.902131998 -0700

"Birth" is the creation date. I don't think cp(1)
duplicates that for a new file. (And it wouldn't
make sense anyway, because it would be the "birth" of
a new file.)

You'll also note that utime(2) and utimes(2) only allow
setting the access and modification times on a file. Please
correct me if I'm wrong, but I don't see a way to change
change time or birth time on a file.

--
-v System76 Thelio Mega v1.1 x86_64 NVIDIA RTX 3090 Ti
OS: Linux 6.11.0-rc4 Release: Mint 21.3 Mem: 258G
"The future isn't what it used to be."

On 2024-08-21 17:25, ambaraba wrote:
> I would like to copy a file
> from srcdir [local HDD "UUID=5AAAA.. /mnt/srcdir  ntfs-3g" in fstab]
> to destdir [network share "//192.168.xx.xx /mnt/destdir ... cifs ..." in
> fstab]
> preserving the original creation date.
> I've tried
> > cp -p /mnt/srcdir/FILE.jpg /mnt/destdir/FILE.jpg
> > rsync -vuart /mnt/srcdir      /mnt/destdir
> > dd ... can't remember the options
> I've also tried with "freefilesync"
> Unfortunately the timestamp on the destination is not preserved :-(
> Is it there a way to
> copy a file (many files) from local to network share
> preserving timestamp ?
> I'm considering "timeshift" but honestly ...
> THANKS for any help

You have to consider that Linux uses three timestamps, but FAT/NTFS
volumes don't.

I just ran a test, using an external usb memory stick formatted FAT. The
time stamp is kept if I use "cp -a":

cer@Telcontar:~> l p
-rw-r--r-- 1 cer users 140 May 25 14:14 p
cer@Telcontar:~> cp p /media/D80B-80D3/
cer@Telcontar:~> l /media/D80B-80D3/p
-rw-r--r-- 1 cer users 140 Aug 23 14:42 /media/D80B-80D3/p
cer@Telcontar:~>

cer@Telcontar:~> stat /media/D80B-80D3/p
File: /media/D80B-80D3/p
Size: 140 Blocks: 64 IO Block: 32768 regular file
Device: 841h/2113d Inode: 2576 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1000/ cer) Gid: ( 100/ users)
Access: 2019-08-04 02:00:00.000000000 +0200
Modify: 2024-08-23 14:42:54.000000000 +0200
Change: 2024-08-23 14:42:54.980000000 +0200
Birth: -
cer@Telcontar:~>

You see that it is not kept with plain "cp". But:

cer@Telcontar:~> rm /media/D80B-80D3/p
cer@Telcontar:~> cp -a p /media/D80B-80D3/
cer@Telcontar:~> l /media/D80B-80D3/p
-rw-r--r-- 1 cer users 140 May 25 14:14 /media/D80B-80D3/p
cer@Telcontar:~> stat /media/D80B-80D3/p
File: /media/D80B-80D3/p
Size: 140 Blocks: 64 IO Block: 32768 regular file
Device: 841h/2113d Inode: 2582 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1000/ cer) Gid: ( 100/ users)
Access: 2024-08-23 02:00:00.000000000 +0200
Modify: 2024-05-25 14:14:42.000000000 +0200
Change: 2024-08-23 14:44:07.900000000 +0200
Birth: -
cer@Telcontar:~>

Let's have a look at a random file on the stick:

cer@Telcontar:~> stat /media/D80B-80D3/elements.txt
File: /media/D80B-80D3/elements.txt
Size: 117 Blocks: 64 IO Block: 32768 regular file
Device: 841h/2113d Inode: 2575 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1000/ cer) Gid: ( 100/ users)
Access: 2024-08-23 02:00:00.000000000 +0200
Modify: 2018-12-17 19:53:36.000000000 +0100
Change: 2018-12-17 20:23:51.000000000 +0100
Birth: -
cer@Telcontar:~>

The "Access" timestamp is the same in both files, so it is not true.

cer@Telcontar:~> l p
-rw-r--r-- 1 cer users 140 May 25 14:14 p
cer@Telcontar:~> stat p
File: p
Size: 140 Blocks: 8 IO Block: 4096 regular file
Device: 825h/2085d Inode: 2901704 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1000/ cer) Gid: ( 100/ users)
Access: 2024-08-23 14:42:54.982156242 +0200
Modify: 2024-05-25 14:14:42.845777574 +0200
Change: 2024-05-25 14:14:42.845777574 +0200
Birth: 2024-05-25 14:14:42.845777574 +0200
cer@Telcontar:~>

--
Cheers, Carlos.