bad Modify timestamps on files copied from OS/2 LANMAN CIFS mount to local filesystem

[mrmazda]

To reproduce:
1-mount an OS/2 or eComStation legacy LANMAN share via CIFS
2-navigate to the mounted share
3-select a file
4-F5 <ENTER>
5-Tab
6-stat the copied file

Actual behavior:

File: `et6g.lst'
Size: 251 Blocks: 2 IO Block: 1024 regular file

Access: (0444/-r--r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
...Modify: 1940-10-23 21:26:18.000000000 -0500...

Expected behavior:

File: `et6g.lst'
Size: 251 Blocks: 2 IO Block: 1024 regular file

Access: (0444/-r--r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
...Modify: 1997-08-26 02:22:26.000000000 -0400...

Notes:
1-expected behavior is from copying file using cp -a instead of mc
2-with older kernels and smbfs mounting of the OS/2 share, mc copy results in correct Modify timestamp
3-CIFS test made using EXT3 target on openSUSE 11.1:

mc-4.6.2.pre1-120.24
cifs-mount-3.2.4-11.5
kernel-pae-2.6.27.7-3.1

4-broken mc behavior is the same with version shipped with openSUSE 11.0 and 10.3 and Fedora 10

[slavazanko]

Need to review internal SAMBA stuff (may me, will replaced by dynamic linking with libsmbclient.so). Then we need to review this ticket.

[zaytsev]

Does this have to do with #1619 ?

[slavazanko]

#1619

[mrmazda]

I'll never understand why people file new bugs when a bug already exists on the subject and then they mark the original older bug as a duplicate of the new bug. This is totally stupid.

[slavazanko]

Replying to mrmazda:

I'll never understand why people file new bugs when a bug already exists on the subject and then they mark the original older bug as a duplicate of the new bug. This is totally stupid.

Because we are peuple, not gods and we may make mistakes. Stupid? Yes. I could close the ticket #1619 as duplicate of this ticket... and I would have done this... but in #1619 now have branch and one vote. I think, better to close other 'empty' tickets so than this 'filled' ticket.

#1619 now 'filled' because I don't searched for duplicates before start work with ticket. This my mistake, sorry :(

[mrmazda]

Searching for existing bug is step one in filing a new bug ​http://www.midnight-commander.org/wiki#Contribute

So "forgetting" is not acceptable excuse.

[slavazanko]

mrmazda, thank you for this lesson. For me it is a good experience.

I changed wiki#Contribute

[zaytsev]

Slava, what's up? I mean come on, it's ridiculous... Who cares about who reported the bug first? I think this one ( ​http://www.midnight-commander.org/ticket/119 ) was the first one anyway.

mrmazda, tell this to the reporter of new bug, OK? What a stupid attitude of yours. The essential is for this bug to get fixed and while triaging bugs I personally don't care about the priority of the reporters. You want to get a medal for reporting it first or what?

[mrmazda]

Most triagers, including me on multiple bug trackers, are volunteers. Those who don't bother searching before filing waste triagers donated time, which is incentive for them to stop triaging altogether.

bug 119 was an enhancement bug about default settings. It's unlikely a search for the broken behavior bad timestamps on copy could have found it, though a search for the problem reported in bug 1619 might have. Either way, 119 might better be a dep of 1619 than a dupe.

I won't be surprised if a 1619 fix fails to fix this due to CIFS problems with legacy OS/2 LANMAN shares. I hope I'm wrong.

[zaytsev]

Replying to mrmazda:

Most triagers, including me on multiple bug trackers, are volunteers. Those who don't bother searching before filing waste triagers donated time, which is incentive for them to stop triaging altogether.

That sounds as if me or Slava get paid to triage bugs. Surprise!!! We don't get paid for that. Maybe we should stop working on mc altogether?

bug 119 was an enhancement bug about default settings. It's unlikely a search for the broken behavior bad timestamps on copy could have found it, though a search for the problem reported in bug 1619 might have. Either way, 119 might better be a dep of 1619 than a dupe.

OK, I am wrong about #119 (add will reopen it), it is indeed about the persistence of the "Preserve attributes" option. The bug #273 was introduced by the resolution of #72, which was later reported again as #1619 (not Slava's fault). The reason why #273 was closed and not #1619 was already explained above: the developer overlooked this one and already started a branch for another ticket.

Of course your reaction to this was to state that this developer is stupid and there is no excuse for him. What a nice way to get along with people.

I won't be surprised if a 1619 fix fails to fix this due to CIFS problems with legacy OS/2 LANMAN shares. I hope I'm wrong.

You don't need to hope, you know, bug fixing is not a religion. Just check it and reopen if the problem is not fixed. My guess that it has nothing to do specifically with this VFS and it's a more general problem as it fixed the problem with CIFS shares for me.

[slavazanko]

To All: please, stop speech.

Someone was wrong when fill new duplicate, I was wrong when start work with duplicate...

This is life and shit happens :)

[mrmazda]

I have ​http://ftp5.gwdg.de/pub/linux/mandrivalinux/devel/cooker/i586/media/main/release/mc-4.7.0.3-1mdv2010.1.i586.rpm installed (dated 27 Feb 2010). Files copied from OS/2 LANMAN shares still land with 1940-10-23 date.

[mrmazda]

Broken also on openSUSE 11.3's 4.7.0.7

[mrmazda]

In 4.7.0.9 (openSUSE Factory 11.4 with 2.6.36rc4 kernel & cifs-utils 4.6-1.3) behavior is slightly different. Now the files on mounted OS/2 LANMAN shares display in the MC panels with correct timestamps, but copying to a local filesystem results in an Oct 23, 1940 timestamp all local copies. Upon completion of a copy, the source timestamp changes to Oct 23, 1940, but only until another panel refresh occurs, whereupon it changes back to a correct timestamp.

[mrmazda]

This bug remains as before comment 16 in 4.7.5.1.

[mrmazda]

Brokenness remains in 4.8.8.

[mrmazda]

File copied from remote to local is still being stamped 23 Oct 1940 in 4.8.13 using cifs-utils-6.4, kernel 3.16.12, but source panel listing retains correct timestamp.