FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > ArchLinux > ArchLinux Pacman Development

 
 
LinkBack Thread Tools
 
Old 04-29-2008, 03:39 AM
"Dan McGee"
 
Default Rework extract_single_file() temp file creation

On Mon, Apr 28, 2008 at 10:34 PM, Dan McGee <dan@archlinux.org> wrote:
> We were a bit juryrigged using one call to mkstemp() before rather than
> extracting the new files side-by-side and doing our comparisons there. We
> were also facing some permissions issues. Instead, make our life easier by
> extracting all temp files to a '.paccheck' extension, doing our md5
> comparisons, and then taking the correct actions.
>
> Still to be done here- a cleanup of the use of PATH_MAX which should not be
> necessary if we use dynamic allocation on the heap.
>
> Signed-off-by: Dan McGee <dan@archlinux.org>
> ---

I posted these patches here because I would love to get some feedback
on them from you guys, and they need some real-life testing. The
biggest catch with this patch is ensuring we don't leave any paccheck
files behind, as we can no longer always unlink the original file
since we use rename instead of copy.

All of these can be found on my public 'working' branch if you are
tracking my GIT repository. I'll hold off a few days before pushing
these to master.

-Dan

_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 
Old 04-29-2008, 07:57 AM
Xavier
 
Default Rework extract_single_file() temp file creation

On Tue, Apr 29, 2008 at 5:39 AM, Dan McGee <dan@archlinux.org> wrote:
> On Mon, Apr 28, 2008 at 10:34 PM, Dan McGee <dan@archlinux.org> wrote:
> > We were a bit juryrigged using one call to mkstemp() before rather than
> > extracting the new files side-by-side and doing our comparisons there. We
> > were also facing some permissions issues. Instead, make our life easier by
> > extracting all temp files to a '.paccheck' extension, doing our md5
> > comparisons, and then taking the correct actions.
> >
> > Still to be done here- a cleanup of the use of PATH_MAX which should not be
> > necessary if we use dynamic allocation on the heap.
> >
> > Signed-off-by: Dan McGee <dan@archlinux.org>
> > ---
>
> I posted these patches here because I would love to get some feedback
> on them from you guys, and they need some real-life testing. The
> biggest catch with this patch is ensuring we don't leave any paccheck
> files behind, as we can no longer always unlink the original file
> since we use rename instead of copy.
>
> All of these can be found on my public 'working' branch if you are
> tracking my GIT repository. I'll hold off a few days before pushing
> these to master.
>

At least it builds fine on cygwin, and make check is fine too
And reading the code, it looks fine too.
Just about this paccheck issue, do we really need to do it that way
and have to worry about it?
Why can't we just let the unlink call? If the file is here, it will
always be removed. If its not here anymore, unlink will fail but that
doesn't matter.
Otherwise an explicit stat could be made to see if the file is still here.
But maybe you find this ugly and prefer handling everything manually,
at the risk of leaving some files behind in case we missed something?

But if we keep your patch as is, there are some failure cases where
you kept the paccheck on purpose, right?
Every time the rename call fails, there is no unlink. But I doubt this
happens often anyway, so no big problem I guess.

_______________________________________________
pacman-dev mailing list
pacman-dev@archlinux.org
http://archlinux.org/mailman/listinfo/pacman-dev
 

Thread Tools




All times are GMT. The time now is 12:54 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org