Bug 144047 - fish mtime year loss
Summary: fish mtime year loss
Alias: None
Product: Fedora
Classification: Fedora
Component: mc   
(Show other bugs)
Version: 1
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jindrich Novy
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2005-01-04 03:01 UTC by Curtis Doty
Modified: 2013-07-02 23:04 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-04-02 15:08:47 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Curtis Doty 2005-01-04 03:01:27 UTC
Description of problem:

A fish filesystem opened in 2004 does not properly copy the mtime in
2005 for files modified in 2005.

Version-Release number of selected component (if applicable):

Version     : 4.6.0                             Vendor: Red Hat, Inc.
Release     : 17.fc1                        Build Date: Sat Aug 21
10:27:52 2004
Install Date: Sun Sep  5 18:25:14 2004      Build Host:
Group       : System Environment/Shells     Source RPM:

How reproducible:

Open a fish session in December. Transfer files from remote to local
and observe proper mtime handling. Now wait until January and copy
some files modified in 2005. Now all files copied from remote to local
will be dated last year but with the proper month/day/etc.

At least I think this is an mc bug...

Comment 1 Jindrich Novy 2005-03-17 19:36:56 UTC
Hello Curtis, are you able to reproduce this also with the mc-4.6.1-pre3 or
later mc (available in FC2/FC3 and the latest in rawhide)?

Comment 2 Jindrich Novy 2005-04-02 15:08:47 UTC
If the issue persists, please report it to mc-devel@gnome.org so that more
developers can have a look at it. Closing WONTFIX now because FC1 is no more
supported (moved to Fedora Legacy).

Note You need to log in before you can comment on or make changes to this bug.