Ticket #273 (reopened defect)

Opened 15 years ago

Last modified 3 years ago

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

Reported by: mrmazda Owned by:
Priority: major Milestone: Future Releases
Component: mc-vfs Version: 4.7.0.3
Keywords: Cc:
Blocked By: Blocking:
Branch state: no branch Votes for changeset:

Description

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

Change History

comment:1 Changed 15 years ago by slavazanko

  • Blocked By 1 added
  • Milestone changed from 4.7 to future releases

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

comment:2 Changed 15 years ago by zaytsev

  • severity set to no branch

Does this have to do with #1619 ?

Last edited 3 years ago by andrew_b (previous) (diff)

comment:3 Changed 15 years ago by slavazanko

  • Status changed from new to closed
  • Resolution set to duplicate
  • Blocked By 1 removed

comment:4 Changed 15 years ago by slavazanko

  • Version 4.6.2-pre1 deleted
  • Milestone future releases deleted

comment:5 follow-up: ↓ 6 Changed 15 years ago by 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.

comment:6 in reply to: ↑ 5 Changed 15 years ago by 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 :(

comment:7 Changed 15 years ago by 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.

comment:8 Changed 15 years ago by slavazanko

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

I changed wiki#Contribute

comment:9 Changed 15 years ago by 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?

Version 0, edited 15 years ago by zaytsev (next)

comment:10 follow-up: ↓ 11 Changed 15 years ago by 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.

comment:11 in reply to: ↑ 10 Changed 15 years ago by 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.

comment:12 Changed 15 years ago by 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 :)

comment:13 Changed 14 years ago by mrmazda

  • Status changed from closed to reopened
  • Resolution duplicate deleted

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.

comment:14 Changed 14 years ago by andrew_b

  • Version set to 4.7.0.3
  • Component changed from mc-core to mc-vfs
  • Milestone set to 4.7

comment:15 Changed 14 years ago by mrmazda

Broken also on openSUSE 11.3's 4.7.0.7

comment:16 Changed 14 years ago by 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.

comment:17 Changed 13 years ago by mrmazda

This bug remains as before comment 16 in 4.7.5.1.

comment:18 Changed 12 years ago by andrew_b

  • Branch state set to no branch
  • Milestone changed from 4.7 to Future Releases

comment:19 Changed 11 years ago by mrmazda

Brokenness remains in 4.8.8.

comment:20 Changed 10 years ago by 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.

Note: See TracTickets for help on using tickets.