On Thu, Feb 02, 2006 at 01:02:51PM +0100, Grzegorz Nosek wrote:
> 2006/2/1, Herbert Poetzl <herbert@13thfloor.at>:
> > > - If I modify a file's contents the CoW link is broken properly but
> > > after a chmod or chown the link is not broken and I get -EPERM (as the
> > > files are marked immutable) - is this expected behaviour? In such a
> > > situation the links aren't exactly CoW...
> >
> > interesting observation, well, strictly speaking
> > chmod or chow are no writes, so CoW is not involved,
> > but I will look into extending the CoW behaviour
> > to those operations in the future ...
>
> Yeah, I know chown isn't really a write but I thought (or maybe I
> felt) that unification shouldn't ever cause an -EPERM error (just
> break the link instead).
>
> It definitely isn't a show stopper for me as I found this behaviour
> after unifying a bit too much of the test vservers but it would be a
> nice feature to have. I came across this when one of my postinstall
> scripts barfed when it tried to sanitise permissions on some files
> (just a blind chown/chmod without prior testing).
yea, shouldn't be too hard to allow for that ...
> BTW, how does the unification react to files owned by different users?
> i.e. /some/file is totally identical between two vservers (wrt.
> contents, timestamps and access mode) but is owned by different users
> (e.g. root:admin on both but on one group admin is gid 7000 and on the
> other it is 8000 or whatever). AIUI it won't be unified at all, right?
yes, identical files with different inode attributes
have to be considered 'different' and (hopefully)
will not be unified ...
best,
Herbert
> Best regards,
> Grzegorz Nosek
> _______________________________________________
> Vserver mailing list
> Vserver@list.linux-vserver.org
> http://list.linux-vserver.org/mailman/listinfo/vserver
_______________________________________________
Vserver mailing list
Vserver@list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver
Received on Thu Feb 2 12:38:41 2006