bug-stow
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-stow] address@hidden: Bug#133243: stow deletes directories it d


From: Guillaume Morin
Subject: Re: [Bug-stow] address@hidden: Bug#133243: stow deletes directories it did not create if they're empty.]
Date: Thu, 14 Feb 2002 00:09:21 +0100
User-agent: Mutt/1.3.27i

Dans un message du 12 fév à 16:51, Gaël Roualland écrivait :
> Yes, that might be a saner behavior actually... Thinking on how stow
> operates, it is theorically not possible to have a directory populated by
> links to only one package, since then stow will create the directory as a
> link to the package directory, instead of linking its contents. So if we
> happen to be in the situation where we have a directory with only links to
> one package, it was probably not created by stow (or somebody unstowed
> something not in the stow way).

If /usr/local is handled only by stow, it should not happen. But I think
it is rarely the case (even on my boxes). The reported bug shows how
that could happen by just making a subdir of /usr/local.

> However, we have to think of this issue together with the wanted "fast
> unstow" functionnality: I guess to do that, we need to scan the package
> for it's files and directories, and check in the target directory if
> there are links to it where expected, instead of scanning the target
> directory for links to the package. 

Right.

> What about "expanded directory" then ? Suppose we have a common
> directory "stuff" with files from two packages "A" and "B". As said
> before, unstowing "A" the regluar way will turn the "stuff" directory
> into a link to "B/stuff". But would the "fast unstow" do that too ?
> (which requires scanning the "stuff" directory and its subdirectories
> for links and check if they all point to the same package -- this
> would be more or less like scanning the whole target directory for a
> package spanning several current directories). If not, then we might
> create empty directories on purpose, and knowing wether we need to
> leave them or not would not be as easy...

I think we should not `expand directories' for fast unstowing. If we
document the fact that in some cases `fast unstowing' could leave some
leftovers, I guess it is ok. Imho the best would be to print warnings as
I suggested in my previous message.

Do you agree with those statements ? If you do and wants to work on the
patch, be my guest :-)

Regards,

-- 
Guillaume Morin <address@hidden>

         Do you worry that you're not liked ? How long till you break
                                (Our Lady Peace)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]