On Tue October 28 2008, Michael S. Zick wrote: > On Tue October 28 2008, Ed W wrote: > > I think we are slightly cross purposes. > > > > Your use case is valid and works as expected. I was just pointing out > > that there exist some minor use cases where you want hardlinks *within* > > a vserver to stay as hardlinks even if any one link is edited (ie no > > autobreaking), whilst having autolink breaking *across* vservers. > > Something like selective hardlink breaking. > > > > OK, I understand what you want now. > > I am not sure how CoW and hardlinking works across "tagged" files. > If the xid tag is a component of the name entry, you might be able > to do it, if it is a component of the inode, then your sol. > > You want the hardlinks managed by device:inode:xid - > if a link has to be broken, then only all files of an xid group > should be effected. I don't know the VFS well enough to comment on that. > > > > Anyway, I think it's a fairly minor usecase so I will drop talking about > > it now! > > > > You should be able to script it - at least a "fix up" script - - > I don't know if the inotify system can handle sending an event to > userspace when CoW happens, but if it does, then that could drive > your "fix it up" scripting. > > Strange as it may seem, I need to look at the inotify system today, > will try to keep my eyes open for that possibility if it isn't already > in the system. I can't make any promises, don't hold your breath. > Since 2.6.25 - you can add an inotify_watch for changes in metadata, including link count. you can also use the sigaction/select system to monitor for inotify events. so you should be able to script/code something userland that does the "fixups by vserver instance" that you want. Ref: man inotify (you will also need a glibc >= 2.5) Mike > Mike > > > > Cheers > > > > Ed W > > > > > > > >