Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problem with "preserve attributes", file times and ntfs/vfat partitions #1619

Closed
mc-butler opened this issue Sep 15, 2009 · 17 comments
Closed
Assignees
Labels
area: core Issues not related to a specific subsystem prio: medium Has the potential to affect progress
Milestone

Comments

@mc-butler
Copy link

Important

This issue was migrated from Trac:

Origin https://midnight-commander.org/ticket/1619
Reporter bilbo (@bilbo2)
Mentions mrmazda@….net

In changeset [78f01a3] there was added detection of filesystem and defaulting to turning off "preserve attributes" on certain FS (ntfs, vfat and some others)

I guess this is because chown and sometimes even chmod can fail on these filesystems, resulting in many annoying messageboxes "chown failed on <file>" or alike.

Unfortunately, this turns off preserving timestamp as well, which is VERY bad. Before I noticed this behavior, this managed to do some damage (mtimes of many backed up files got lost, so I needed to recreate those backups again).

Suggested fix:

  1. always copy time/date of files
  1. There are more attributes for files (mtime, ctime, permissions, owner, group, possibly some ACL on some systems), so add once checkbox for date/time, one for permissions and one for owner/group. Perhaps another for ACL, once (if) they'll be supported in MC.
  1. have "preserve attributes" checked on always by default, but add "ignore failure to set all attributes" checkbox. This would solve also cases where another new "simple" filesystem without support for chmod/chgrp/chown appears, like recent ex-fat.

Or perhaps somewhat combine these solutions.

@mc-butler
Copy link
Author

Changed by slavazanko (@slavaz) on Sep 15, 2009 at 22:55 UTC (comment 1)

  • Milestone changed from 4.7 to 4.7.0-pre3

@mc-butler
Copy link
Author

Changed by zaytsev (@zyv) on Sep 16, 2009 at 8:06 UTC (comment 2)

3) is actually a good idea.

I wrecked quite a few backups lately because of this and I was SOOO annoyed... Hopefully they were not very important anyway. Still I've never got time to add this to the tracker.

There is another problem related to this. Even it preserve attributes is set, FISH would set the year to the current year (2009) when copying files using SSH. This also needs to be investigated.

@mc-butler
Copy link
Author

Changed by slavazanko (@slavaz) on Sep 18, 2009 at 12:20 UTC (comment 3)

  • Severity changed from no branch to on review
  • Status changed from new to accepted
  • Priority changed from critical to major
  • Owner set to slavazanko

created branch 1619_preserve_attributes_timestamp (parent: master)

initial [c3507f868a18a11817aed0b7298e1be3cdc1acad]

review.

@mc-butler
Copy link
Author

Changed by iNode (@iNode) on Sep 22, 2009 at 9:18 UTC (comment 4)

346 line now useless.

@mc-butler
Copy link
Author

Changed by slavazanko (@slavaz) on Sep 22, 2009 at 9:57 UTC (comment 5)

346? Is you mean 746?

Yes, line is useless.

Fixed: [b6d9b619ffa4c49dbd1126253f69aa73c88430c6]

@mc-butler
Copy link
Author

Changed by iNode (@iNode) on Sep 22, 2009 at 10:36 UTC (comment 6)

  • Votes set to iNode

Yes I mean 746.

@mc-butler
Copy link
Author

Changed by zaytsev (@zyv) on Sep 25, 2009 at 12:29 UTC (comment 7)

  • Blocking set to #119

I think that #119 is a dupe, no?

@mc-butler
Copy link
Author

Changed by slavazanko (@slavaz) on Sep 25, 2009 at 13:26 UTC

  • Blocking #119 deleted

(In #119) #1619

@mc-butler
Copy link
Author

Changed by slavazanko (@slavaz) on Sep 25, 2009 at 13:33 UTC

(In #1639) No. #1619 just about fixing timestamps with unchecked 'preserve attributes' option.

This ticket about always turned on 'preserve attributes' option.

@mc-butler
Copy link
Author

Changed by slavazanko (@slavaz) on Sep 25, 2009 at 13:41 UTC (comment 10)

I think that #119 is a dupe, no?

Yes, looks like duplicate. #273 too.

@mc-butler
Copy link
Author

Changed by mrmazda (mrmazda@….net) on Sep 25, 2009 at 13:43 UTC (comment 11)

  • Cc set to mrmazda@….net

This bug should be closed as a duplicate of the much earlier filed bug 273, not the other way around as was done.

@mc-butler
Copy link
Author

Changed by slavazanko (@slavaz) on Sep 25, 2009 at 13:58 UTC (comment 12)

This bug should be closed as a duplicate of the much earlier filed bug 273, not the other way around as was done.

See #273 for answer.

@mc-butler
Copy link
Author

Changed by angel_il (@ilia-maslakov) on Sep 25, 2009 at 21:44 UTC (comment 13)

  • Votes changed from iNode to iNode angel_il

@mc-butler
Copy link
Author

Changed by angel_il (@ilia-maslakov) on Sep 25, 2009 at 21:44 UTC (comment 14)

  • Severity changed from on review to approved

@mc-butler
Copy link
Author

Changed by slavazanko (@slavaz) on Sep 25, 2009 at 21:56 UTC (comment 15)

  • Votes changed from iNode angel_il to commited-master
  • Severity changed from approved to merged
  • Blocking #1639 deleted

merge [ea631fa]

@mc-butler
Copy link
Author

Changed by slavazanko (@slavaz) on Sep 25, 2009 at 21:56 UTC (comment 16)

  • Resolution set to fixed
  • Status changed from accepted to testing

@mc-butler
Copy link
Author

Changed by slavazanko (@slavaz) on Sep 28, 2009 at 6:54 UTC (comment 17)

  • Status changed from testing to closed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: core Issues not related to a specific subsystem prio: medium Has the potential to affect progress
Development

No branches or pull requests

2 participants