cp -p does not preserve timestamps

[Jochen Roderburg]

Hello list,

This favourite linux-cifs error seems to be still around (or returned  
again lately  ;-)

When I copy a file to a cifs-mounted share, in most cases the time  
stamps are not preserved. I see this with "cp -p" and the GNOME  
commander file-manager and with various combinations of Linux clients  
and samba servers:
with Linux kernels 2.6.28 and 2.6.29, samba 3.2.7 on an IBM SoFS  
system (kind of huge NAS which we are about to release upon our  
university staff/students), samba 3.0.25 on an own NAS box (Acer  
EasyStore) and samba 3.3.4 on my Linux machines themselves. The  
problem seems to occur only with enabled CIFS Unix Extensions.

I have searched in the net and the cifs archives and saw that this  
type of error was already discussed and repaired several times in  
recent years. I have found also two test programs in the archives with  
which I can show the error in some of the above mentioned cases. As I  
said it does not occur in every case which makes it kind of difficult  
to diagnose.

What I read in the old discussions is that this issue happens in cases  
where file attributes (incl. timestamps) are set on open files and the  
subsequent file close resets them again somehow.

Let me know if I can help with specific tests on my systems. I have,  
however, the feeling that is not difficult to reproduce the error in  
other environments, too.

Best Regards,

Jochen Roderburg
RRZK
University of Cologne
Robert-Koch-Str. 10                    Tel.:   [phone]
D-50931 Koeln                          E-Mail: Roderburg@...
Germany


_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

[Günter Kukkukk-2]

Am Sonntag, 7. Juni 2009 schrieb Jochen Roderburg:

> Hello list,
>
> This favourite linux-cifs error seems to be still around (or returned  
> again lately  ;-)
>
> When I copy a file to a cifs-mounted share, in most cases the time  
> stamps are not preserved. I see this with "cp -p" and the GNOME  
> commander file-manager and with various combinations of Linux clients  
> and samba servers:
> with Linux kernels 2.6.28 and 2.6.29, samba 3.2.7 on an IBM SoFS  
> system (kind of huge NAS which we are about to release upon our  
> university staff/students), samba 3.0.25 on an own NAS box (Acer  
> EasyStore) and samba 3.3.4 on my Linux machines themselves. The  
> problem seems to occur only with enabled CIFS Unix Extensions.
>
> I have searched in the net and the cifs archives and saw that this  
> type of error was already discussed and repaired several times in  
> recent years. I have found also two test programs in the archives with  
> which I can show the error in some of the above mentioned cases. As I  
> said it does not occur in every case which makes it kind of difficult  
> to diagnose.
>
> What I read in the old discussions is that this issue happens in cases  
> where file attributes (incl. timestamps) are set on open files and the  
> subsequent file close resets them again somehow.
>
> Let me know if I can help with specific tests on my systems. I have,  
> however, the feeling that is not difficult to reproduce the error in  
> other environments, too.
>
> Best Regards,
>
> Jochen Roderburg

have checked that against samba 3.3.x and most recent 3.4.x.
Your problem is reproducible in both versions - looks like a
samba server bug (as seen from wireshark traces and debug logs).
Please file a bug report on https://bugzilla.samba.org/

Cheers, Günter
_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

[Günter Kukkukk-2]

Am Sonntag, 7. Juni 2009 schrieb Jochen Roderburg:

> Hello list,
>
> This favourite linux-cifs error seems to be still around (or returned  
> again lately  ;-)
>
> When I copy a file to a cifs-mounted share, in most cases the time  
> stamps are not preserved. I see this with "cp -p" and the GNOME  
> commander file-manager and with various combinations of Linux clients  
> and samba servers:
> with Linux kernels 2.6.28 and 2.6.29, samba 3.2.7 on an IBM SoFS  
> system (kind of huge NAS which we are about to release upon our  
> university staff/students), samba 3.0.25 on an own NAS box (Acer  
> EasyStore) and samba 3.3.4 on my Linux machines themselves. The  
> problem seems to occur only with enabled CIFS Unix Extensions.
>
> I have searched in the net and the cifs archives and saw that this  
> type of error was already discussed and repaired several times in  
> recent years. I have found also two test programs in the archives with  
> which I can show the error in some of the above mentioned cases. As I  
> said it does not occur in every case which makes it kind of difficult  
> to diagnose.
>
> What I read in the old discussions is that this issue happens in cases  
> where file attributes (incl. timestamps) are set on open files and the  
> subsequent file close resets them again somehow.
>
> Let me know if I can help with specific tests on my systems. I have,  
> however, the feeling that is not difficult to reproduce the error in  
> other environments, too.
>
> Best Regards,
>
> Jochen Roderburg

this bug has been fixed now in 3.2.x / 3.3.x and today released 3.4.x - see also
https://bugzilla.samba.org/show_bug.cgi?id=6520

Thanks for reporting! :-)
Cheers, Günter
_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

[Jochen Roderburg]

Zitat von Günter Kukkukk <linux@...>:

> Am Sonntag, 7. Juni 2009 schrieb Jochen Roderburg:
>> Hello list,
>>
>> This favourite linux-cifs error seems to be still around (or returned
>> again lately  ;-)
>>
>> When I copy a file to a cifs-mounted share, in most cases the time
>> stamps are not preserved. I see this with "cp -p" and the GNOME
>> commander file-manager and with various combinations of Linux clients
>> and samba servers:
>> with Linux kernels 2.6.28 and 2.6.29, samba 3.2.7 on an IBM SoFS
>> system (kind of huge NAS which we are about to release upon our
>> university staff/students), samba 3.0.25 on an own NAS box (Acer
>> EasyStore) and samba 3.3.4 on my Linux machines themselves. The
>> problem seems to occur only with enabled CIFS Unix Extensions.
>>
>> I have searched in the net and the cifs archives and saw that this
>> type of error was already discussed and repaired several times in
>> recent years. I have found also two test programs in the archives with
>> which I can show the error in some of the above mentioned cases. As I
>> said it does not occur in every case which makes it kind of difficult
>> to diagnose.
>>
>> What I read in the old discussions is that this issue happens in cases
>> where file attributes (incl. timestamps) are set on open files and the
>> subsequent file close resets them again somehow.
>>
>> Let me know if I can help with specific tests on my systems. I have,
>> however, the feeling that is not difficult to reproduce the error in
>> other environments, too.
>>
>> Best Regards,
>>
>> Jochen Roderburg
>
> this bug has been fixed now in 3.2.x / 3.3.x and today released  
> 3.4.x - see also
> https://bugzilla.samba.org/show_bug.cgi?id=6520
>
> Thanks for reporting! :-)
> Cheers, Günter

Hello Günter,

Thanks for carrying this issue over to the samba side of things and  
informing me about the results. ;-)
I had more or less given up already. A short search in the samba  
bugzilla brought up only one related entry and I did not have the  
impression that anybody was actually working on it. I see the bug 6520  
now mentioned in the just released samba 3.4. The latest 3.2/3.3  
releases were before your new bugzilla discussion, so I think they  
cannot appear there before another release of these.

Unfortunately the outcome of the whole case is now so that these  
bugfixes to not help me at all with my actual problems. Changes on the  
client side would have been more helpful, because I could apply them  
on the systems which are under my own control. I cannot change the  
samba server on IBM's SoFS system or on my NAS boxes. so I must  
continue with the workaround to disable the "unix extensions". I  
decided for me that in my cases correct time-stamps are more important  
than the other extension features. In both situations the shared file  
store is mainly used for system-independent backups.

Best regards,
Jochen Roderburg

_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

[Jeff Layton-2]

On Sun, 2009-07-05 at 17:57 +0200, Jochen Roderburg wrote:

> Zitat von Günter Kukkukk <linux@...>:
>
> > Am Sonntag, 7. Juni 2009 schrieb Jochen Roderburg:
> >> Hello list,
> >>
> >> This favourite linux-cifs error seems to be still around (or returned
> >> again lately  ;-)
> >>
> >> When I copy a file to a cifs-mounted share, in most cases the time
> >> stamps are not preserved. I see this with "cp -p" and the GNOME
> >> commander file-manager and with various combinations of Linux clients
> >> and samba servers:
> >> with Linux kernels 2.6.28 and 2.6.29, samba 3.2.7 on an IBM SoFS
> >> system (kind of huge NAS which we are about to release upon our
> >> university staff/students), samba 3.0.25 on an own NAS box (Acer
> >> EasyStore) and samba 3.3.4 on my Linux machines themselves. The
> >> problem seems to occur only with enabled CIFS Unix Extensions.
> >>
> >> I have searched in the net and the cifs archives and saw that this
> >> type of error was already discussed and repaired several times in
> >> recent years. I have found also two test programs in the archives with
> >> which I can show the error in some of the above mentioned cases. As I
> >> said it does not occur in every case which makes it kind of difficult
> >> to diagnose.
> >>
> >> What I read in the old discussions is that this issue happens in cases
> >> where file attributes (incl. timestamps) are set on open files and the
> >> subsequent file close resets them again somehow.
> >>
> >> Let me know if I can help with specific tests on my systems. I have,
> >> however, the feeling that is not difficult to reproduce the error in
> >> other environments, too.
> >>
> >> Best Regards,
> >>
> >> Jochen Roderburg
> >
> > this bug has been fixed now in 3.2.x / 3.3.x and today released  
> > 3.4.x - see also
> > https://bugzilla.samba.org/show_bug.cgi?id=6520
> >
> > Thanks for reporting! :-)
> > Cheers, Günter
>
> Hello Günter,
>
> Thanks for carrying this issue over to the samba side of things and  
> informing me about the results. ;-)
> I had more or less given up already. A short search in the samba  
> bugzilla brought up only one related entry and I did not have the  
> impression that anybody was actually working on it. I see the bug 6520  
> now mentioned in the just released samba 3.4. The latest 3.2/3.3  
> releases were before your new bugzilla discussion, so I think they  
> cannot appear there before another release of these.
>
> Unfortunately the outcome of the whole case is now so that these  
> bugfixes to not help me at all with my actual problems. Changes on the  
> client side would have been more helpful, because I could apply them  
> on the systems which are under my own control. I cannot change the  
> samba server on IBM's SoFS system or on my NAS boxes. so I must  
> continue with the workaround to disable the "unix extensions". I  
> decided for me that in my cases correct time-stamps are more important  
> than the other extension features. In both situations the shared file  
> store is mainly used for system-independent backups.
>
> Best regards,
> Jochen Roderburg

You may want to test the client-side patchset I posted on Thursday:

Subject: [linux-cifs-client] [PATCH 0/3] cifs: add a SET_FILE_INFO variant that uses FILE_UNIX_BASIC_INFO infolevel

It may help this problem as well.

--
Jeff Layton <jlayton@...>

_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client

[Jochen Roderburg]

Zitat von Jeff Layton <jlayton@...>:

>
> You may want to test the client-side patchset I posted on Thursday:
>
> Subject: [linux-cifs-client] [PATCH 0/3] cifs: add a SET_FILE_INFO  
> variant that uses FILE_UNIX_BASIC_INFO infolevel
>
> It may help this problem as well.
>

This looks interesting, too, as the "issue" seems to be triggered by  
programs doing "settime calls" on open file-handles.

Pardon me some more questions, as I'm not familiar with your  
development system: How could I test these patches? Could I apply them  
directly to the cifs sources in a current Linux kernel? Or is there a  
publicly accessible source repository somewhere, which has the patches  
already? I did not find any information on the website  
http://linux-cifs.samba.org (which, btw, does not look very current  
generally ;-)

Best regards,
Jochen Roderburg


_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@...
https://lists.samba.org/mailman/listinfo/linux-cifs-client