Re: Issues with /tmp/mc-$USER directory

[Koblinger Egmont <egmont uhulinux hu>]

Hi!

> I don't want to delete the directory on exit because there are many
> reasons why mc can exit (including crash and killing it when rebooting the
> system).  Considering that the temporary directory may have huge files in
> it, I would prefer to have a fixed name for it, so that it could be easily
> cleaned up by scripts if mc exists without cleaning some files.

Removal could only happen when mc exits cleanly. E.g. the removal of that
directory tree could be executed when F10 is pressed (and confirmed). This
way it isn't removed when mc crashes or is killed.

Using fix file names under /tmp is impossible without risking security.
You can use fix file names under your home, or a unique non-existant
filename under /tmp. However, you can still use filenames that match the
pattern /tmp/mc-$USER-* or similar, which might help cleanup scripts a
lot. It is also possible to check whether /tmp/mc-$USER exists (and try to
create it and see if it's successful) and use it if it's yours, and only
fallback to some other ugly name if it is stolen by someone else.

> mkdtemp would be great if it was more portable.  "info libc" says it comes
> from OpenBSD, so I don't think you can find mkdtemp on every UNIX.

Maybe some configure-check for whether it is available... Sorry, I'm not
familiar with any Unices other than Linux. Alternatively an own
implementation would be good which creates random filenames and tries to
open them with O_EXCL. If it succeeds, that file/dir is yours. Maybe take
a look at the glibc sources how these calls are implemented there :))

> It is important to have a fallback for the case if something is wrong with
> the temporary directory.  Midnight Commander should be useful even on
> systems with all filesystems mounted read-only.

But I guess we only expect the very basic features of mc to work, not the
virtual file system, nor the -P option when the system doesn't even have a
writeable /tmp. Am I right?


> Any help with this fix will be appreciated.  All other issues have been
> addressed.  As soon as this issue is fixed, 4.6.0-pre2 will be released.

Shall I write patches and send them to you to see if you like them? Or
should I just try to figure out what should be done and leave the
implementation to you?


bye,
Egmont