After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 333324 - graft does not get created in directory specified by /apps/nautilus-cd-burner/temp_iso_dir
graft does not get created in directory specified by /apps/nautilus-cd-burner...
Status: RESOLVED OBSOLETE
Product: nautilus-cd-burner
Classification: Deprecated
Component: cd-burner
2.14.x
Other All
: Normal normal
: ---
Assigned To: Nautilus CD Burner Maintainers
Nautilus CD Burner Maintainers
Depends on:
Blocks:
 
 
Reported: 2006-03-04 02:41 UTC by Michael Gratton
Modified: 2009-07-29 10:45 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14


Attachments
Patch (7.49 KB, patch)
2006-06-12 16:04 UTC, Fabio Bonelli
none Details | Review

Description Michael Gratton 2006-03-04 02:41:50 UTC
Please describe the problem:
Setting the gconf key /apps/nautilus-cd-burner/temp_iso_dir does not change the
directory the ISO is actually created in.

Steps to reproduce:
1. Set gconf key /apps/nautilus-cd-burner/temp_iso_dir to some directory other
than /tmp
2. Write a CD

Actual results:
When hitting write, an ISO file gets created in the specified tmp directory, but
nothing seems to be written to it - its file size stays at 0. Instead, the ISO
is actually created in /tmp.


Expected results:
When hitting write, the ISO file gets created in the specified tmp directory.


Does this happen every time?
Yes.

Other information:
TMPDIR is unset in my session, but running nautilus-cd-burner with that set
seems to be a workaround.
Comment 1 Fabio Bonelli 2006-03-04 08:10:40 UTC
Can't reproduce this on my machine.

Have you got the permissions to write in that directory?
Comment 2 Michael Gratton 2006-03-05 01:31:28 UTC
Yep:

mjg@continuity:~$ ls -ld ~/tmp
drwxr-sr-x 10 mjg mjg 12288 2006-03-04 15:07 /home/mjg/tmp

I had a closer look at this, and it seems that maybe it is some pre-processing is filling up /tmp, rather than the ISO itself.

After I hit write, a zero-length ISO file is created in the directory specified by the temp_iso_dir key. Also, the directory /tmp/iso-$USER-.$SOME_RANDOM_THING is created and that starts getting filled up with a whole bunch of subdirectories called "subdir.$SOME_RANDOM_THING". These directories seem to contain the content for the ISO.

If I set TMPDIR and run n-c-b from the command line (eg: mjg@continuity:~$ TMPDIR=~/tmp nautilus-cd-burner) then the directory iso-$USER-.$SOME_RANDOM_THING actually gets created in the location specified by $TMPDIR, and the burn works.

So it isn't the ISO that is getting created in the wrong place, it is all these temporary files.
Comment 3 Fabio Bonelli 2006-03-05 10:33:53 UTC
Hello Mike,

Help me to understand correctly: the bug is actually about the ISO *not* being created, because of /tmp filled by some of the temporary files needed to build it and the operation fails silently. Am I right?

These files together should reach a size of few KiB (if not, please paste the sizes), I don't think it would be right to write them to the temp_iso_dir directory as that directory is, as the name says, for the iso.

We should display an error if we fill /tmp, IMO.
Comment 4 Michael Gratton 2006-03-05 13:15:54 UTC
Hi Fabio,

Yes, you are right - /tmp gets filled up completely with temporary files used for building the ISO, so the ISO never gets made. I agree that an appropriate error message should be displayed when the filesystem used gets full.

However I also think that it would be good if the directory specified by the gconf key /apps/nautilus-cd-burner/temp_iso_dir is also used for locating those temporary files. After all, if /tmp does not have enough space for the ISO, it will not have enough for the temporary files, either.
Comment 5 Fabio Bonelli 2006-03-28 14:52:04 UTC
Can you provide the size of the temporary files?

I'm surprised because they should be 2 or 3 order of magnitude smaller than the ISO file.
Comment 6 Michael Gratton 2006-06-04 05:14:41 UTC
[updated subject to reflect the real problem]

I've had a look at this a bit more, the problem is with the graft creation process for mkisofs.

If you look in make-iso.c, both create_temp_dir and create_temp_file use g_get_tmp_dir to create temporary filesystem objects, I think this is why the files are getting created in /tmp rather than in the directory specified by the /apps/nautilus-cd-burner/temp_iso_dir gconf key.

Looking at the graft filelist, it contains entries like:

vee.net/web/static/stuff/slackfest/2000/jorn/=/tmp/iso-mjg.B2esTw/subdir.vZ1wJd

Looking in those directories, they contain copies of the files to be burnt:

$ ls -l /tmp/iso-mjg.B2esTw/subdir.vZ1wJd/
total 9130
-rw-r--r-- 1 mjg mjg 150150 2006-06-04 14:15 dcp02347.jpg
-rw-r--r-- 1 mjg mjg 227232 2006-06-04 14:15 dcp02348.jpg
[snip]
$

So the contents of the directories that for whatever reason cannot be used in-place get copied into these temp directories. Hence for large burns and/or small amounts of space left on /tmp, the ISO creation fails. I have seen a graft ~270Mb big for a 700Mb burn and is a significant problem for me - to use ncb I need to always launch it manually.

If create_temp_dir (and maybe create_temp_file?) was changed to use the temp directory from gconf rather than g_get_tmp_dir, then nautilus_burn_iso_graft_new would cause the graft to be created in the correct directory.

Would it be possible to call get_temp_path_gconf directly from create_temp_dir and create_temp_file?
Comment 7 Fabio Bonelli 2006-06-12 16:04:32 UTC
Created attachment 67195 [details] [review]
Patch

Indeed the files are copied...

This should fix the bug, could you take a look and see if it fixes the issue for you?
Comment 8 Fabio Bonelli 2006-11-20 12:46:04 UTC
Mike?
Comment 9 Bastien Nocera 2009-07-29 10:45:54 UTC
nautilus-cd-burner has been replaced by Brasero in the GNOME 2.26 release. If your bug still applies to Brasero, please feel free to re-open the bug, and reassign it to brasero itself.