Hi,
Adam Purkrt wrote:
> the backup files are there (see below).
> -rw-r--r-- 1 root root 127089 May 28 10:15 ast.mo~
(Second big sigh of relief.)
> Perhaps, even though the
> renaming and unlinking in strace look it is paired, somewhere between
> the renames and unlinks xorriso is called by grub-mkrescue, and the unlinks
> only takes place after the run; still, the files get deleted after
> unsuccessful run of xorriso, hence they are not seen without your wrapper
> script.
Yes. That was the last straw to clutch before filing the problem as
unexplainable.
The /tmp filesystem seems to keep the dirents of the .mo~ files until
the process, which has unlinked them, has ended. That would be the
grub-mkrescue process which lasts until the xorriso process has ended
and then does some cleanup stuff.
At the end of util/grub-mescue.c, this is the xorriso run:
rv = grub_util_exec ((const char *const *)xorriso_argv);
if (rv != 0)
grub_util_error ("`%s` invocation failed\n", "xorriso");
and these are the cleanup actions which affect the /tmp filesystem
(the content of iso9660_dir was "/tmp/grub.xrifVw" in your run):
grub_util_unlink_recursive (iso9660_dir);
if (sysarea_img)
grub_util_unlink (sysarea_img);
The grub_util_error() call after the intentional xorriso failure
obviously ends the process without cleanup. Nevertheless the .mo~ files
are gone afterwards.
So the call to grub_util_unlink_recursive() is not needed to get rid of
them. (It is of course needed to get rid of the other yet not unlinked
files, which you see after a failed xorriso run.)
You could underpin the theory about delayed file removal at process end
by a call of grub_util_exec() immediately before the final return 0.
Untested (and dirty and possibly cluelessly immitating correct coding):
xorriso_arg[0]= "ls";
xorriso_arg[1]= grub_util_path_concat(2, iso9660_dir, "boot/grub/locale");
xorriso_arg[2]= NULL;
grub_util_exec ((const char *const *)xorriso_argv);
If my theory is right, then the .mo~ files should be still to see by
this gesture after a successful xorriso run.
Further you could try to reproduce the strange delay of file removal
by simpler means without running grub-mkrescue and xorriso.
Especially it would be interesting to see if the delay is specific
to the /tmp fileystem or whether it happens with others too.
I guess this would have to be done by a C program or alike.
If in a shell script /bin/rm unlinks a file, then to my theory the
file becomes unavailable when /bin/rm ends. So there would be no chance
to look for it.
Have a nice day :)
Thomas
