Re: [Quilt-dev] Fix mode on backup files

[Andreas Gruenbacher]

Hello,

On Wednesday 02 June 2004 01:50, Dean Roehrich wrote:
> >From:  Andreas Gruenbacher <address@hidden>
> >
> >> @@ -239,7 +240,7 @@
> >>                    if (link_or_copy(file, &st, backup))
> >>                            return 1;
> >>                    if (opt_nolinks) {
> >> -                          if (ensure_nolinks(file))
> >> +                          if (ensure_nolinks(backup))
> >>                                    return 1;
> >
> >The idea here was to ensure that the original file doesn't have more
> >than one hardlink after a patch touches it (or after a patch is
> >removed). This makes it a lot less likely that a file is modified while
> >its backup file is modified at the same time. I don't understand why
> >that would matter for the backup file.
>
> Perhaps in the what_backup case we should call ensure_nolinks for both the
> original and the backup?
>
> I'm thinking about the case where someone edits one of the other links,
> without having used 'quilt add' on it, and now the backup has changed, and
> the patch won't pop cleanly...

Well, you won't run into this problem unless you work on a hard-linked tree in 
the first place. If you do, I think it's reasonable to assume that you do 
take care, no?

Quilt also has a little ugliness when restoring backup files right now, by the 
way: It ensures that after a restore, files have a reference count of one, 
too. So even with a hard linked tree, after push/pop, you will end up with 
copied files. The reason for this is simple: The patch that ends up on top 
after tot pop might touch some of the files that were popped, so those files 
might end up having more then one hard link after a restore without this 
hack. A more reasonable fix would be to pop all patches that need to be 
popped, and ensure the single-link property only for the patch that ends up 
on top after that compound operation. This would speed up things a little, 
but I'm not sure by how much. Also, backup-files.c should really walk the .pc 
directory itself, instead of reading the list from a file that must first be 
generated. Oh well, so many ideas and so little time...

There is an interesting kernel patch that puts a mark on inodes that prevents 
hard-linked files from being trashed, btw. It's not very likely that this 
patch will end up in mainline anytime soon, but the approach is still very 
interesting. The broader plan was to implement copy-on-write, but the 
implications to this are somewhat unclear: Inode numbers would change; POSIX 
doesn't allow this.

Cheers,
-- 
Andreas Gruenbacher <address@hidden>
SUSE Labs, SUSE LINUX AG