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

[ak]

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

[ak]

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

[andrew_b]

Branch: 4000_extfs_remove_nested_archives.
Initial changeset:8a18d66d05692edb8140a14563ad578dfbfa7c1a

Please test.

[ak]

Replying to andrew_b:

Branch: 4000_extfs_remove_nested_archives.
Initial changeset: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

[andrew_b]

Merged to master: [c281e7c6ed20de8e03bbe016fe60cf1ba646cd9f].

git log --pretty=oneline c853a4fbf..c281e7c6e