HELMER%SDNET.BITNET@vm1.nodak.edu (Guy Helmer) (07/26/89)
I've ported David Clunie's yacc to MINIX successfully except for one problem: no obvious working replacement for rename() seems to be available. I've tried using link(oldname, newname); unlink(oldname);, but link() apparently doesn't like to work over mount points even if the new file and old file are to exist on the same file system. The only thing that seems to be left to do is the equivalent of 'cp <oldfile> <newfile>' and then unlink(oldname). Does anyone have a better suggestion? Thanks in advance. -- Guy Helmer BITNET: HELMER@SDNET Dakota State University Computing Services Madison, SD 57042
root@cca.ucsf.edu (Systems Staff) (07/26/89)
In article <20454@louie.udel.EDU>, HELMER%SDNET.BITNET@vm1.nodak.edu (Guy Helmer) writes: > I've ported David Clunie's yacc to MINIX successfully except for > one problem: no obvious working replacement for rename() system -- issue a shell command (Section 3, Unix User's Manual) mv -- move or rename files (Section 1, Unix User's Manual) thus system("mv <oldfile> <newfile>"); > I've tried using link(oldname, newname); unlink(oldname);, > but link() apparently doesn't like to work over mount points even > if the new file and old file are to exist on the same file system. I find this confusing: going over mount points appears to be the essence of different file systems. What do you mean here? It is correct for links (i.e. hard as opposed to symbolic links) not to connect between file systems. > The only thing that seems to be left to do is the equivalent > of 'cp <oldfile> <newfile>' and then unlink(oldname). Does anyone I presume this should be "<oldfile>" --------^^^^^^^ > have a better suggestion? Thanks in advance. The latter sequence is about equivalent to _mv_ for the case where the two names refer to different filesystems (mv also sets the time and date info on the new copy). Of course, as written the example is mixing program execution (cp) and library call (unlink). Thos Sumner Internet: thos@cca.ucsf.edu (The I.G.) UUCP: ...ucbvax!ucsfcgl!cca.ucsf!thos BITNET: thos@ucsfcca U.S. Mail: Thos Sumner, Computer Center, Rm U-76, UCSF San Francisco, CA 94143-0704 USA OS|2 -- an Operating System for puppets. #include <disclaimer.std>
HELMER%SDNET.BITNET@vm1.nodak.edu (Guy Helmer) (07/26/89)
Thos Sumner writes: >In article <20454@louie.udel.EDU>, HELMER%SDNET.BITNET@vm1.nodak.edu (Guy > Helmer) writes: >> I've ported David Clunie's yacc to MINIX successfully except for >> one problem: no obvious working replacement for rename() > > system -- issue a shell command (Section 3, Unix User's Manual) > mv -- move or rename files (Section 1, Unix User's Manual) >thus > system("mv <oldfile> <newfile>"); > Ugh... Not exactly the beautiful, simple, fast executing trick I was looking forward to seeing... >> I've tried using link(oldname, newname); unlink(oldname);, >> but link() apparently doesn't like to work over mount points even >> if the new file and old file are to exist on the same file system. > >I find this confusing: going over mount points appears to be the essence >of different file systems. What do you mean here? It is correct for >links (i.e. hard as opposed to symbolic links) not to connect between >file systems. > Under minix, link("/tmp/oldfile", "/tmp/newfile") doesn't work for me. When I tried it, this path traversed a mount point on my system, but I (apparently incorrectly) hoped that it would still work. I don't have V7 docs nor do I have real un*x to try this out, so I don't really know what is supposed to work. >> The only thing that seems to be left to do is the equivalent >> of 'cp <oldfile> <newfile>' and then unlink(oldname). Does anyone >I presume this should be "<oldfile>" --------^^^^^^^ >> have a better suggestion? Thanks in advance. > >The latter sequence is about equivalent to _mv_ for the case where >the two names refer to different filesystems (mv also sets the time >and date info on the new copy). Of course, as written the example >is mixing program execution (cp) and library call (unlink). I was thinking of writing code to do the equivalent of a 'cp', and then do the unlink(). I'm trying to avoid fork() and exec() like the plague :-) ; yacc really doesn't need to be any slower. I have a new thought, though; would link() work if I did something like this: getcwd(curpath); chdir("/tmp"); link("oldname", "newname"); unlink("oldname"); chdir(curpath); It seems to me like this would be the best replacement possible for rename on Minix. > > > Thos Sumner Internet: thos@cca.ucsf.edu > (The I.G.) UUCP: ...ucbvax!ucsfcgl!cca.ucsf!thos > BITNET: thos@ucsfcca > > U.S. Mail: Thos Sumner, Computer Center, Rm U-76, UCSF > San Francisco, CA 94143-0704 USA > >OS|2 -- an Operating System for puppets. > >#include <disclaimer.std>
dtynan@altos86.Altos.COM (Dermot Tynan) (07/27/89)
In article <20510@louie.udel.EDU>, HELMER%SDNET.BITNET@vm1.nodak.edu (Guy Helmer) writes: Thos Sumner writes: [Aside: Hi Thos, did you get the stuff I mailed you???] > Under minix, link("/tmp/oldfile", "/tmp/newfile") doesn't work for > me. When I tried it, this path traversed a mount point on my system, but > I (apparently incorrectly) hoped that it would still work. > I don't have V7 docs nor do I have real un*x to try this out, > so I don't really know what is supposed to work. I don't understand this. You're not crossing any mount points with this one. If Minix doesn't allow you to do the link, then Minix is broken. What error-code is returned by 'link'??? Have you looked in the source? (You *do* have a Minix source licence, don't you :-) Your chdir() version should work also, although it is an ugly hack, and should only be used as a temporary measure. The reason 'link' won't allow you to cross a mount point, is because the true ID for a file, is not just its inode, but the dev/inode pair. As such, an inode on one device has no meaning on another device. In your case above, both files are on the same filesystem, and Minix has no excuse not to link them together. - Der -- dtynan@altos86.Altos.COM (408) 946-6700 x4237 Dermot Tynan, Altos Computer Systems, San Jose, CA 95134 "Far and few, far and few, are the lands where the Jumblies live..."
HELMER%SDNET.BITNET@vm1.nodak.edu (Guy Helmer) (07/27/89)
Dermont Tynan writes: >In article <20510@louie.udel.EDU>, HELMER%SDNET.BITNET@vm1.nodak.edu (Guy > Helmer) writes: > >> Under minix, link("/tmp/oldfile", "/tmp/newfile") doesn't work for >> me. When I tried it, this path traversed a mount point on my system, but >> I (apparently incorrectly) hoped that it would still work. >> I don't have V7 docs nor do I have real un*x to try this out, >> so I don't really know what is supposed to work. > >I don't understand this. You're not crossing any mount points with this >one. If Minix doesn't allow you to do the link, then Minix is broken. >What error-code is returned by 'link'??? Have you looked in the source? >(You *do* have a Minix source licence, don't you :-) Yes! At least I should :-)) >Your chdir() version should work also, although it is an ugly hack, and >should only be used as a temporary measure. The reason 'link' won't >allow you to cross a mount point, is because the true ID for a file, is >not just its inode, but the dev/inode pair. As such, an inode on one >device has no meaning on another device. In your case above, both files >are on the same filesystem, and Minix has no excuse not to link them >together. > - Der I jumped the gun when I blamed link() for not working. I forgot my un*x internals and thought that link() knew that "/tmp/whatever" was a path that was crossing mount points as it was parsing the path; I then thought maybe link() assumed that it couldn't link the files. My mistake, and sorry for the inconvenience to everyone. -- Guy Helmer