https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959211
On 4/30/20 3:52 PM, The Wanderer wrote:
On 2020-04-30 at 15:27, Alberto Sentieri wrote:
I run tcpdump while running my simple program on both stretch and
buster. On stretch, x2 uses SMB (version 1, I guess) protocol, while
on buster it u
Thanks for the information. I will enter a bug report asking for a fix
for the last stretch available samba server. Or maybe for cifs-utils on
buster side.
On 4/30/20 3:52 PM, The Wanderer wrote:
On 2020-04-30 at 15:27, Alberto Sentieri wrote:
I run tcpdump while running my simple program on
On 2020-04-30 at 15:27, Alberto Sentieri wrote:
> I run tcpdump while running my simple program on both stretch and
> buster. On stretch, x2 uses SMB (version 1, I guess) protocol, while
> on buster it uses SMB2 (version 2 or 3).
>
> So, the problem can be solved by adding vers=1.0 to mount.cifs
I run tcpdump while running my simple program on both stretch and
buster. On stretch, x2 uses SMB (version 1, I guess) protocol, while on
buster it uses SMB2 (version 2 or 3).
So, the problem can be solved by adding vers=1.0 to mount.cifs options.
Any version from 2.0 and above will incur in t
1 second, 3 seconds or 10 minutes have the same result.
About the 1024 1K-blocks, if one checks the file size on the samba
server using the same command, the return will be:
4 -rwxrw-r-- 1 root cifsusers 10 Feb 5 2017 test2.txt
So, it is using only 4Kbytes on the server. I have no id
On Thu 30 Apr 2020 at 12:46:26 (-0400), Alberto Sentieri wrote:
> Apparently there is something wrong with the debian stretch utimensat
> system call, or with its interaction with cifs. It works as expected
> when the destination file is on a ext4 file system, but it does not
> work when the destin
Hi,
Alberto Sentieri wrote:
> ls -ls "${NAME}"
> Note that the /mnt/u1/rw/receipt is a SMB folder. I got this result:
> 1024 -rwxr-xr-x 1 u1 u1 10 Apr 30 12:20 /mnt/u1/rw/receipt/test2.txt
> [...]
> I run the same binary and script on my debian stretch workstation, and got
> 4 -rwxr-xr-x 1 u1 u1 1
Apparently there is something wrong with the debian stretch utimensat
system call, or with its interaction with cifs. It works as expected
when the destination file is on a ext4 file system, but it does not work
when the destination file is on a SMB file system.
I wrote a simple C program, whi
Thanks.
By any chance is there a cifs specialist watching this thread?
Apparently the timestamp is initially correct but it changes after a
while. Does anyone knows why? Is there a worker finishing the file copy,
which could be creating this effect?
I wrote the following script to repeat my
Hi,
Alberto Sentieri wrote:
> I tried setfattr as you suggested with "user" and without "user". Both
> failed with "Operation not supported" and none of them changed the
> timestamp.
This only leaves the idea to mimick the strace of cp -p in an own
C program to see whether utimensat() has the des
I tried setfattr as you suggested with "user" and without "user". Both
failed with "Operation not supported" and none of them changed the
timestamp.
On 4/29/20 5:31 PM, Thomas Schmitt wrote:
Hi,
assumed that the success of "touch" indicates that utimensat(2) works
fine, i would pick the faile
I am using ls -ls to check the data.
As captured from my screen:
$ rm /mnt/u1/rw/receipt/u1.crontab
$ ls -ls /mnt/1g/home/u1/data/u1.crontab /mnt/u1/rw/receipt/u1.crontab
ls: cannot access '/mnt/u1/rw/receipt/u1.crontab': No such file or directory
4 -rw-r--r-- 1 u1 u1 54 Feb 5 2017 /mnt/1g/hom
Exactly as shown on my screen, it shows that rsync, when used with -av,
works as expected, but cp -pi does not.
$ rm /mnt/u1/rw/receipt/u1.crontab
$ ls -ls /mnt/1g/home/u1/data/u1.crontab /mnt/u1/rw/receipt/u1.crontab
ls: cannot access '/mnt/u1/rw/receipt/u1.crontab': No such file or directory
On Wed 29 Apr 2020 at 15:07:52 (-0400), Alberto Sentieri wrote:
> When I tried strace with /bin/cp -pi I can see on both commands
> something like this:
>
> utimensat(4, NULL, [{tv_sec=1588174263, tv_nsec=908624390} /*
> 2020-04-29T11:31:03.908624390-0400 */, {tv_sec=1486350336,
> tv_nsec=48142233
Alberto Sentieri wrote:
> On 4/29/20 4:13 PM, Thomas Schmitt wrote:
>> Hi,
>>
>> Alberto Sentieri wrote:
>>> It is clear
>>> there that -p has no effect on that particular case of smb destinations. A
>>> similar problem is happening with mv.
>> Maybe its not the file copying operation but the subse
Hi,
assumed that the success of "touch" indicates that utimensat(2) works
fine, i would pick the failed fsetxattr(2) as next suspect.
Does this set the timestamps despite failing ?
setfattr -n user.test_name -v test_value /mnt/u1/rw/receipt/u1.crontab
(I expect an "Operation not supported" er
Just to document what I've seen so far:
These are some straces which may help finding the problem:
1) cp -p from ext4 to smb, debian buster, which failed:
utimensat(4, NULL, [{tv_sec=1588174263, tv_nsec=908624390} /*
2020-04-29T11:31:03.908624390-0400 */, {tv_sec=1486350336,
tv_nsec=48142233
The content file is copied correctly. And touch works as expected on smb
files. The command below produced the expected results:
touch -t 201901011300 /mnt/u1/rw/receipt/u1.crontab
On 4/29/20 4:13 PM, Thomas Schmitt wrote:
Hi,
Alberto Sentieri wrote:
It is clear
there that -p has no effect
Hi,
Alberto Sentieri wrote:
> It is clear
> there that -p has no effect on that particular case of smb destinations. A
> similar problem is happening with mv.
Maybe its not the file copying operation but the subsequent adjustment
of the timestamps.
Did you already try whether you can change times
Charles,
Please read the whole thread, which starts at
https://lists.debian.org/debian-user/2020/04/msg01361.html. It is clear
there that -p has no effect on that particular case of smb destinations.
A similar problem is happening with mv.
I resurrect my stretch workstation and the behavior
On Wed, 29 Apr 2020 12:22:41 -0400
Alberto Sentieri <2...@tripolho.com> wrote:
> cp and mv are not preserving the file timestamps when copying from a
> ext4 file system to a smb file system.
What I see is:
* mv does preserve the time of the file, regardless of copying to an
SMB share or not.
When I tried strace with /bin/cp -pi I can see on both commands
something like this:
utimensat(4, NULL, [{tv_sec=1588174263, tv_nsec=908624390} /*
2020-04-29T11:31:03.908624390-0400 */, {tv_sec=1486350336,
tv_nsec=481422339} /* 2017-02-05T22:05:36.481422339-0500 */], 0) = 0
The utimensat is
Exactly the same behavior for /bin/cp and /bin/mv. I do not have any other cp
or mv in my path.
$ sha1sum /bin/cp /bin/mv
220687a082fb9d0dbb48e9a2b1093cbb4e9de55a /bin/cp
46e71d67df7eb1c41f8f8c9039f401e242cce94a /bin/mv
On Wed, Apr 29, 2020 at 12:22:41PM -0400, Alberto Sentieri wrote:
cp a
On Wed, Apr 29, 2020 at 12:22:41PM -0400, Alberto Sentieri wrote:
> cp and mv are not preserving the file timestamps when copying from a ext4
> file system to a smb file system.
>
> I am running cp and mv on:
> $ lsb_release -a
> No LSB modules are available.
> Distributor ID: Debian
> Descript
cp and mv are not preserving the file timestamps when copying from a
ext4 file system to a smb file system.
I am running cp and mv on:
$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 10 (buster)
Release: 10
Codename: buster
SMB is
25 matches
Mail list logo
