Prev: ~~~~~~~~~~~~~~ RAM LINE ~~~~~~~~~~~~~~
Next: Sneak Peak: AT-Robots clone implemented in Java.
From: root on 28 Dec 2009 13:13
Suppose I have a series of linked files:
a->b->c->....->endfile

So that endfile is a real file and a,b,c..
are links to one another.

I would like to enter the list at any point,
modify the file, and preserve the links.

For example, I might modify b, without
regard for the fact that b is only a link.
The modification would apply to endfile,
but I have to then set the links b->c...
to now preserve that destination endfile.

Assume that I have opened, as a file,
somepoint along the chain, modified the
data and written it to a temporary file tempname.

Without regard to the links, I could
use:
unlink(linkname);
rename(tempname,linkname);

which destroys the link chain and leaves
some the old endfile around, and other
links to it.

I have sketched out code using readlink(),
symlink(), and rename using a recursive
call to readlink:

#define LSIZE 512
dolinx(original,tempname)
char *original,*tempname;
{
int nl;
char buff[LSIZE];

nl=readlink(original,tempname);
buff[nl]=0;
if(nl){
dolinx(buff,tempname);
symlink(oldfile,buff);
}
else{
rename(tempfile,oldfile);
}
}

I can see that pathnames are not correctly
handled in the final rename. Is there a
code snippet that you can point me to that
does the job correctly?

TIA
From: Ben Bacarisse on 29 Dec 2009 07:04
root <NoEMail(a)home.org> writes:

> Suppose I have a series of linked files:
> a->b->c->....->endfile
>
> So that endfile is a real file and a,b,c..
> are links to one another.

a, b, c and so on are therefore symbolic links, yes? I put it like
that because you can only really get a chain like with symbolic
links.

> I would like to enter the list at any point,
> modify the file, and preserve the links.

OK. I can't yet see where the problem is.

> For example, I might modify b, without
> regard for the fact that b is only a link.

How do you modify the symbolic link b without regard for the fact that
it is a link? Did you mean that you modify endfile by opening it
through the chain of links?

> The modification would apply to endfile,
> but I have to then set the links b->c...
> to now preserve that destination endfile.

If the links are symbolic ones I don't see why they need to be "set"
at all. If the links are hard links and endfile is unlinked and
created anew then you have a problem, but you also don't have a chain
of links, simply lots of alternate names for the old endfile (which
still exists, of course).

> Assume that I have opened, as a file,
> somepoint along the chain, modified the
> data and written it to a temporary file tempname.
>
> Without regard to the links, I could
> use:
> unlink(linkname);
> rename(tempname,linkname);
>
> which destroys the link chain and leaves
> some the old endfile around, and other
> links to it.
>
> I have sketched out code using readlink(),
> symlink(), and rename using a recursive
> call to readlink:

I think you are using hard links from this description. Can you
simply switch to using symbolic links? You would then have a chain,
and the links would be correct as some as the modified endfile was
renamed "endfile" again.

<snip>

PS. comp.unix.programmer might be a better place for this.

--
Ben.
From: unruh on 29 Dec 2009 13:03
["Followup-To:" header set to alt.comp.linux.]
On 2009-12-29, Ben Bacarisse <ben.usenet(a)bsb.me.uk> wrote:
> root <NoEMail(a)home.org> writes:
>
>> Suppose I have a series of linked files:
>> a->b->c->....->endfile
>>
>> So that endfile is a real file and a,b,c..
>> are links to one another.
>
> a, b, c and so on are therefore symbolic links, yes? I put it like
> that because you can only really get a chain like with symbolic
> links.
>
>> I would like to enter the list at any point,
>> modify the file, and preserve the links.
>
> OK. I can't yet see where the problem is.
>
>> For example, I might modify b, without
>> regard for the fact that b is only a link.
>
> How do you modify the symbolic link b without regard for the fact that
> it is a link? Did you mean that you modify endfile by opening it
> through the chain of links?
>
>> The modification would apply to endfile,
>> but I have to then set the links b->c...
>> to now preserve that destination endfile.
>
> If the links are symbolic ones I don't see why they need to be "set"
> at all. If the links are hard links and endfile is unlinked and
> created anew then you have a problem, but you also don't have a chain
> of links, simply lots of alternate names for the old endfile (which
> still exists, of course).
>
>> Assume that I have opened, as a file,
>> somepoint along the chain, modified the
>> data and written it to a temporary file tempname.
>>
>> Without regard to the links, I could
>> use:
>> unlink(linkname);
>> rename(tempname,linkname);

That is your mistake. Remember that a link IS just a file, a special
file, which points to another file. Buy unlinking it, you destroyed that
file.
Instead copy tempname to linkname, and then remove tempname.
Of course, that has the problem that if something happens in the midst
of that copy ( which could take a while) you destroy the original file.


>>
>> which destroys the link chain and leaves
>> some the old endfile around, and other
>> links to it.
>>
>> I have sketched out code using readlink(),
>> symlink(), and rename using a recursive
>> call to readlink:
>
> I think you are using hard links from this description. Can you
> simply switch to using symbolic links? You would then have a chain,
> and the links would be correct as some as the modified endfile was
> renamed "endfile" again.

No he is using soft links. But he is breaking the links in the middle.
His program in editing or changing the file "b" copies it to a temp
file, say b.tmp. He then alters b.tmp. He then renames b.tmp to b (mv
b.tmp b) which erases the file b, which is the link, and replaces it
with a regular file whose contents are the old contents of b.tmp. But
that breaks the chain. If he edited the file "b" in place (did not copy
to a temporary file) or copied the contents of b.tmp to b and then
erased b.tmp he would not have this problem. But he insists of moving (
renaming) b.tmp thus destroying the soft link.


From: root on 30 Dec 2009 00:12
Ben Bacarisse <ben.usenet(a)bsb.me.uk> wrote:
>
><snip>
>
> PS. comp.unix.programmer might be a better place for this.
>

Thanks for responding. My problem was easily resolved
by following the links and only modifying the
endfile. The links take care of themselves.
 | 
Pages: 1
Prev: ~~~~~~~~~~~~~~ RAM LINE ~~~~~~~~~~~~~~
Next: Sneak Peak: AT-Robots clone implemented in Java.