GNOME Bugzilla – Bug 598702
Add g_file_copy_to_temp
Last modified: 2009-11-19 13:54:38 UTC
It would be nice if GIO had convenience code to copy an existing file to a temporary place, without having to do it all by hand. The return value would tell you the location of the newly created temporary file.
I'd be using this in Totem's browser plugin, as WebKit removes temporary files as soon as a function returns, so we need to hold a copy of it.
This seems a little bit 'too magic' to have in GIO. I can't imagine very many users of it. I also can't imagine it ever being used for a non-local filesystem. You can very easily use one of the mktemp functions and then just copy over top of the file that it creates for you. That should always be safe.
(In reply to comment #2) > This seems a little bit 'too magic' to have in GIO. I can't imagine very many > users of it. I also can't imagine it ever being used for a non-local > filesystem. Does it being useful for non-local filesystems matter? I'm not asking for gvfs API, but for gio one. > You can very easily use one of the mktemp functions and then just copy over top > of the file that it creates for you. That should always be safe. No, it's not... mktemp will create a filename. The only time that filename will ever be "safe" is when you read from the file descriptor that you created fast enough to avoid races. If the file was moved, renamed, shot in the head, you wouldn't know about it. The only way to make this work is using mkstemp() which means implementing the whole copy by hand.
(In reply to comment #3) > Does it being useful for non-local filesystems matter? I'm not asking for gvfs > API, but for gio one. Adding the call to GFile implies that you might want to use it on any GFile. It would be very strange if it didn't also work for remote files. > The only way to make this work is using mkstemp() which means implementing the > whole copy by hand. Right. That's what I meant.
(In reply to comment #4) > Right. That's what I meant. Wait. No. That's not what I meant. You're right that mktemp() won't do the right thing at all and that mkstemp is needed. What's what I meant by "Right." I meant to create the file using mkstemp and then using the normal GFile copy to copy over top of the file that was safely created by that. Once you create a file in /tmp, nobody can rename or delete it for you (because of the sticky bit). The only security/race problem you have to protect against here is if you are attempting to attack yourself.....
(In reply to comment #5) > I meant to create the file using mkstemp and then using the normal GFile copy > to copy over top of the file that was safely created by that. Once you create > a file in /tmp, nobody can rename or delete it for you (because of the sticky > bit). The only security/race problem you have to protect against here is if > you are attempting to attack yourself..... mkstemp gives you a file descriptor, not a filename. You don't know the name of the file that was created on disk, just its file descriptor.
It modifies the template string you pass it in-place. The XXXXXX is replaced with the actual characters used.
Alex mentioned that I could use mkstemp and do a g_file_copy with G_FILE_COPY_TARGET_DEFAULT_PERMS as a flag, which is good enough for my use.