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

mc 4.8.23 - extfs data in /tmp/mc-USERNAME not deleted after closing mc (rpm/cpio + deb) #4000

Closed
mc-butler opened this issue Jul 15, 2019 · 8 comments
Assignees
Labels
area: vfs Virtual File System support prio: medium Has the potential to affect progress ver: 4.8.23 Reproducible in version 4.8.23
Milestone

Comments

@mc-butler
Copy link

Important

This issue was migrated from Trac:

Origin https://midnight-commander.org/ticket/4000
Reporter ak (AxelKoellhofer@….de)
Mentions info@….net (@metux)
Keywords extfs

Since updating to mc 4.8.23 some (but not all, see below) temporary data created in /tmp/mc-username is no longer being deleted after closing mc.

This affects .rpm (cpio?) and .deb files, tar.gz/xz/bz2 do not seem to be affected though.

Example (RPM file):

  • Navigate to a directory containing rpm files.
  • Select a rpm file and press <Enter>, you will get sth. like this and /tmp/mc-username ist still empty:
    |/INFO                       │      0│31. Mai 2018 ││                            │       │             │
    │ CONTENTS.cpio              │      0│31. Mai 2018 ││                            │       │             │
    │ HEADER                     │    859│31. Mai 2018 ││                            │       │             │
    │*INSTALL                    │      0│31. Mai 2018 ││                            │       │             │
    │*REBUILD  
    

If you now select "CONTENTS.cpio" and hit <Enter> again, you will see the files inside the rpm (which as you might know are packed as a cpo archive), and inside /tmp/mc-username a respcetive file

extfs<SOME_CHARACTERS>CONTENTS.cpio

is created.

After closing mc, the file

/tmp/mc-username/extfs<SOME_CHARACTERS>CONTENTS.cpio

is no longer deleted like in older versions of mc (up to 4.8.22).

I also tested some deb-packages with similar results:

Navigate to some deb-package -> press <ENTER> -> select "CONTENTS" folder -> navigate to some file, press F3 to show contents -> /tmp/mc-username/extfs-somename is created and not deleted after closing mc.

As indicated before, version 4.8.22 deletes these temporary files after closing mc, which in my opinion should be the "correct" way of dealing with such temporary files.

Greetings,

AK

@mc-butler
Copy link
Author

Changed by andrew_b (@aborodin) on Jul 16, 2019 at 5:19 UTC (comment 1)

  • Component changed from mc-core to mc-vfs
  • Owner set to andrew_b
  • Status changed from new to accepted
  • Milestone changed from Future Releases to 4.8.24
  • Description edited

@mc-butler
Copy link
Author

Changed by ak (AxelKoellhofer@….de) on Jul 16, 2019 at 9:49 UTC (comment 2)

Addendum:

I did some further testing and maybe found a better description what seems to be the problem.

I was wondering, why "tar.gz/xz/bz2 do not seem to be affected though" and if the problem is really restricted to some types of archives or if there might be some other cause.

I created a tar.xz archive and packed that archive into another archive (tar.xz/bz2/gz, cpio).

Opening the first "shell" of this "nested" (would that be a correct term?) archive works as expected but opening the "archive inside the archive" triggers the problem described in my opening post.

So it seems that "nested" archives are the problem and not (only?) the file type.

Greetings,

AK

@mc-butler
Copy link
Author

Changed by andrew_b (@aborodin) on Aug 6, 2019 at 17:33 UTC (comment 3)

  • Branch state changed from no branch to on review

Branch: 4000_extfs_remove_nested_archives.
Initial [8a18d66d05692edb8140a14563ad578dfbfa7c1a]

Please test.

@mc-butler
Copy link
Author

Changed by ak (AxelKoellhofer@….de) on Aug 6, 2019 at 18:19 UTC (comment 3.4)

Replying to andrew_b:

Branch: 4000_extfs_remove_nested_archives.
Initial [8a18d66d05692edb8140a14563ad578dfbfa7c1a]

Please test.

Yes, this seems do have done the trick.

Note:

I did not check out the whole git tree, I just created a diff against stable 4.8.23 (only containing the respective changes in src/vfs/extfs/extfs.c from the "4000_extfs_remove_nested_archives" branch).

Greetings,

AK

@mc-butler
Copy link
Author

Changed by metux (@metux) on Aug 8, 2019 at 20:26 UTC (comment 5)

  • Cc set to info@….net

@mc-butler
Copy link
Author

Changed by andrew_b (@aborodin) on Aug 10, 2019 at 7:01 UTC (comment 6)

  • Branch state changed from on review to approved
  • Votes set to andrew_b

@mc-butler
Copy link
Author

Changed by andrew_b (@aborodin) on Aug 10, 2019 at 7:02 UTC (comment 7)

  • Status changed from accepted to testing
  • Resolution set to fixed
  • Votes changed from andrew_b to committed-master
  • Branch state changed from approved to merged

Merged to master: [c281e7c].

git log --pretty=oneline c853a4fbf..c281e7c6e

@mc-butler
Copy link
Author

Changed by andrew_b (@aborodin) on Aug 10, 2019 at 7:03 UTC (comment 8)

  • 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: vfs Virtual File System support prio: medium Has the potential to affect progress ver: 4.8.23 Reproducible in version 4.8.23
Development

No branches or pull requests

2 participants