'rm' incompatibility with Posix.2
Hi everyone, I have noticed quite some time ago a strange way in which some basic FreeBSD utilities work, related to symlinks. Example session: bgd@cvs$ mkdir temp bgd@cvs$ ln -s temp b bgd@cvs$ ls -ald temp b lrwxr-xr-x 1 bgd wheel4 Apr 9 11:27 b -> temp drwxr-xr-x 2 bgd wheel 512 Apr 9 11:27 temp bgd@cvs$ rm -rf b/ bgd@cvs$ ls -ald temp b ls: temp: No such file or directory lrwxr-xr-x 1 bgd wheel 4 Apr 9 11:27 b -> temp bgd@cvs$ As you can see, when I tried to remove the symlink 'b' with a trailing slash 'rm -rf b/', the target directory was removed instead of the actual symlink. Of course, this is weird (tryied it on some other 10 un*xes, and all worked in another way). I have attached a patch for the 'rm' untility, which strips the trailing slash(es) from the path (according to Posix.2). But I think there are many other utilities which need to be patched (e.g. cp, mv). Greetings, bogdan 0a1,2 > > 463,470d464 < /* strip trailing slashes, since POSIX.2 defines basename < as the final portion of a path after the trailing slashes < have been removed. <*/ < p = strrchr (*t, '\0'); < while (--p > *t && *p == '/') <*p = '\0'; <
Re: 'rm' incompatibility with Posix.2
"Brian T.Schellenberger" wrote: > On Wednesday 10 April 2002 06:04 pm, Peter Kieser wrote: > | I say we just leave it how it is now. Else alot of people are probably > | going to end up deleting directories by accident. It's perfectly fine how > | it is, if it's not broken why fix it? > > Well, the question is whether it's broken; > > and right now it FreeBSD sometimes deletes directories; the request is to > delete the link instead under those circumstances, so the argument from > "don't avoid directories unless you are certain" would militate in favor of > changing the behavior. I've noticed things getting deleted before, other times I've used the command "rm -rf". I'm glad I'm not the only one seeing this behaviour. 8-) 8-) 8-) 8-). > (Not that I'm advocating such a change. The FreeBSD behavior seems > consistent & sensible to me; the Linux behavior [as described on this list] > does not; other Unices vary, and clearly there is little consistency. None > of which matters if people just avoid trailing slashes. Since trailing > slashes are rarely seen unless they are deliberately being used to mean > something special, I prefer FreeBSD's semantics, which do something useful > with that information over other semantics which always discard that > information.) Trailing slashes "magically" appear in shells that do completion, and in badly fit together scripts, where it's easier to put a trailing slash on a variable content for a directory, then to ensure that there is a "/" prefix on non-empty appended path components (if any -- and the optional nature of them makes it harder). It's validly arguable that an "rm -rf foo/" should remove only "foo", if it is a symlink to a directory, rather than the directory contents. If you were to do an "rm -rf fee/", and "fee/" was a directory containing a symplink "foo" to another directory, you would expect the link, not the target, to be deleted. However... I think that the trailing slash semantics are also arguable, and, being that they are consistant between commands, more correct than anything that results in an inconsistancy. I think the most telling thing is "what do we expect when": cd /tmp mkdir -p foo/fee cp /etc/ttys foo/fee/ttys ln -s foo xyz rm -rf xyz/fee ...we expect it to follow the link "xyz" because of the trailing "/" in the "xyz/" path component. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 'rm' incompatibility with Posix.2
On Wednesday 10 April 2002 06:04 pm, Peter Kieser wrote: | I say we just leave it how it is now. Else alot of people are probably | going to end up deleting directories by accident. It's perfectly fine how | it is, if it's not broken why fix it? Well, the question is whether it's broken; and right now it FreeBSD sometimes deletes directories; the request is to delete the link instead under those circumstances, so the argument from "don't avoid directories unless you are certain" would militate in favor of changing the behavior. (Not that I'm advocating such a change. The FreeBSD behavior seems consistent & sensible to me; the Linux behavior [as described on this list] does not; other Unices vary, and clearly there is little consistency. None of which matters if people just avoid trailing slashes. Since trailing slashes are rarely seen unless they are deliberately being used to mean something special, I prefer FreeBSD's semantics, which do something useful with that information over other semantics which always discard that information.) -- Brian T. Schellenberger . . . . . . . [EMAIL PROTECTED] (work) Brian, the man from Babble-On . . . . [EMAIL PROTECTED] (personal) ME --> http://www.babbleon.org http://www.eff.org <-- GOOD GUYS --> http://www.programming-freedom.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 'rm' incompatibility with Posix.2
Dag-Erling Smorgrav wrote: > Bogdan TARU <[EMAIL PROTECTED]> writes: > > Could you also try the NetBDS's 'rm'? If it does work like FreeBDS, than > > I really don't know what to believe anymore. > > It doesn't, actually, it removes the symlink rather than the directory > it points at. I think ut uses the value of "lstat" instead of "stat" to get the aforementioned behaviour, and specifically excepts a blank component name. This is very different than "removing the trailing '/'". If someone cares enough, I'm sure a FreeBSD developer somewhere has access to the Solaris sources, and can look... the CDROM's have not been out of production that long. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 'rm' incompatibility with Posix.2
Bogdan TARU wrote: > If ending a symlink with a slash is supposed to mean 'refer to the > directory it points to', I imagine ending a directory with a slash is even > more so. Then why, oh, why, 'cp -R' copies only the content of the > directory in the new location > > man cp: > > -RIf source_file designates a directory, cp copies the directory and >the entire subtree connected at that point. > > Why do I have the feeling something goes terribly wrong here? A blank path component implies ".". It always has in BSD. There are man pages to this effect (though you will have to zgrep for them yourself). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 'rm' incompatibility with Posix.2
I say we just leave it how it is now. Else alot of people are probably going to end up deleting directories by accident. It's perfectly fine how it is, if it's not broken why fix it? -- Peter Kieser [EMAIL PROTECTED] This is not about Napster or DVDs. It's about your Freedom. http://www.anti-dmca.org - Original Message - From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Wednesday, April 10, 2002 10:03 AM Subject: Re: 'rm' incompatibility with Posix.2 > > >Please don't. This functionality is extremely useful. Consider this: > > > > It may be useful but it is nonstandard. > > FreeBSD mostly follows standards. But there are several examples of > FreeBSD *not* following standards because the standards are considered > broken. > > In this particular case - I consider the FreeBSD behavior far more > *useful* than the alternative. > > (For those of you with long memories: SunOS used to have the same > behavior as FreeBSD currently does. This changed sometime around SunOS > 4.1.2/4.1.3, and caused a lot of grief at the time. Let's not make the > same mistake with FreeBSD, just because some people claim it's more > standards conformant.) > > Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 'rm' incompatibility with Posix.2
> >Please don't. This functionality is extremely useful. Consider this: > > It may be useful but it is nonstandard. FreeBSD mostly follows standards. But there are several examples of FreeBSD *not* following standards because the standards are considered broken. In this particular case - I consider the FreeBSD behavior far more *useful* than the alternative. (For those of you with long memories: SunOS used to have the same behavior as FreeBSD currently does. This changed sometime around SunOS 4.1.2/4.1.3, and caused a lot of grief at the time. Let's not make the same mistake with FreeBSD, just because some people claim it's more standards conformant.) Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 'rm' incompatibility with Posix.2
Dag-Erling Smorgrav writes: >Please don't. This functionality is extremely useful. Consider this: It may be useful but it is nonstandard. >In my humble opinion, Solaris (and every other *nix) is broken in this >respect, and *BSD is correct. How do you define "correctness"? Solaris ls(1) non-arguably conforms to XPG/4 / SuSV2, the current UNIX(tm) standard, and FreeBSD ls(1) doesn't. On Solaris (and SuSV2), you can get the desired behaviour with ls -f (force interpretation as a directory), which of course collides with BSD ls' "-f Output is not sorted". IMHO standardization and interoperability are more important than a small and questionable gain from using incompatible interfaces. If you want the interface to change, change the standard. And no "the good thing with standards is that there are so many to chose from" rants please; 4.xBSD is not a standard, SuSV2 is and I surely don't want to follow down the path which you hint at with "every other *nix is broken...and *BSD is correct". --mkb (a proponent of /usr/ucb for the incompatible cruft) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 'rm' incompatibility with Posix.2
On Wednesday 10 April 2002 11:21 am, Bogdan TARU wrote: | As well: | | bgd@web$ mkdir temp | bgd@web$ touch temp/a | bgd@web$ mkdir temp2 | bgd@web$ cp -R temp/ temp2/ | bgd@web$ ls -al temp2/ | total 3 | drwxr-xr-x 2 bgd wheel 512 Apr 10 17:20 . | drwxr-xr-x 14 bgd wheel 2048 Apr 10 17:20 .. | -rw-r--r-- 1 bgd wheel 0 Apr 10 17:20 a | | If ending a symlink with a slash is supposed to mean 'refer to the | directory it points to', I imagine ending a directory with a slash is even | more so. Then why, oh, why, 'cp -R' copies only the content of the | directory in the new location | | man cp: | | -RIf source_file designates a directory, cp copies the directory and |the entire subtree connected at that point. | | Why do I have the feeling something goes terribly wrong here? That *would* seem to fly in the face of the previously-cited posix2 requirement. | | bogdan | | | | | | To Unsubscribe: send mail to [EMAIL PROTECTED] | with "unsubscribe freebsd-hackers" in the body of the message -- Brian T. Schellenberger . . . . . . . [EMAIL PROTECTED] (work) Brian, the man from Babble-On . . . . [EMAIL PROTECTED] (personal) ME --> http://www.babbleon.org http://www.eff.org <-- GOOD GUYS --> http://www.programming-freedom.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 'rm' incompatibility with Posix.2
As well: bgd@web$ mkdir temp bgd@web$ touch temp/a bgd@web$ mkdir temp2 bgd@web$ cp -R temp/ temp2/ bgd@web$ ls -al temp2/ total 3 drwxr-xr-x 2 bgd wheel 512 Apr 10 17:20 . drwxr-xr-x 14 bgd wheel 2048 Apr 10 17:20 .. -rw-r--r-- 1 bgd wheel 0 Apr 10 17:20 a If ending a symlink with a slash is supposed to mean 'refer to the directory it points to', I imagine ending a directory with a slash is even more so. Then why, oh, why, 'cp -R' copies only the content of the directory in the new location man cp: -RIf source_file designates a directory, cp copies the directory and the entire subtree connected at that point. Why do I have the feeling something goes terribly wrong here? bogdan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 'rm' incompatibility with Posix.2
Dag-Erling Smorgrav wrote: > Bogdan TARU <[EMAIL PROTECTED]> writes: > > On 10 Apr 2002, Dag-Erling Smorgrav wrote: > > > In my humble opinion, Solaris (and every other *nix) is broken in > > > this > > > respect, and *BSD is correct. > > Except for OpenBDS. No NetBDS machine available, maybe some of you > > could > > try it on one as well? > > I don't know of any "OpenBDS" or "NetBDS", but NetBSD has the same > semantics as FreeBSD: For ls, so do linux, HP-UX, and Digital Unix 4.0 -- I just checked. It does seem the more sensible and useful behaviour. However, without the -l flag the symlink is followed regardless of the trailing / >From Digital Unix: rs> mkdir foo rs> mkdir foo/bar rs> ln -s foo baz rs> ls baz bar/ rs> ls baz/ bar/ rs> ls -l baz lrwxrwxrwx 1 rsiddusers 3 Apr 10 20:43 baz@ -> foo/ rs> ls -l baz/ total 1 drwxr-xr-x 2 rsiddusers512 Apr 10 20:43 bar/ With rm baz/ it's different: linux doesn't follow the symlink, it removes "baz". Digital and HP-UX follow the symlink. All three remove the symlink if specified without the trailing / - Rahul To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 'rm' incompatibility with Posix.2
Bogdan TARU <[EMAIL PROTECTED]> writes: > Could you also try the NetBDS's 'rm'? If it does work like FreeBDS, than > I really don't know what to believe anymore. It doesn't, actually, it removes the symlink rather than the directory it points at. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 'rm' incompatibility with Posix.2
UUps... :) Sorry, OpenBSD and NetBSD (typing fast & wrong, that's what I'm good at). Could you also try the NetBDS's 'rm'? If it does work like FreeBDS, than I really don't know what to believe anymore. bogdan On 10 Apr 2002, Dag-Erling Smorgrav wrote: > Bogdan TARU <[EMAIL PROTECTED]> writes: > > On 10 Apr 2002, Dag-Erling Smorgrav wrote: > > > In my humble opinion, Solaris (and every other *nix) is broken in this > > > respect, and *BSD is correct. > > Except for OpenBDS. No NetBDS machine available, maybe some of you could > > try it on one as well? > > I don't know of any "OpenBDS" or "NetBDS", but NetBSD has the same > semantics as FreeBSD: > > des@rc4 ~% mkdir foo > des@rc4 ~% touch foo/bar > des@rc4 ~% ln -s foo baz > des@rc4 ~% ls -l baz > lrwxr-xr-x 1 des des 3 Apr 10 16:41 baz@ -> foo > des@rc4 ~% ls -l baz/ > total 0 > -rw-r--r-- 1 des des 0 Apr 10 16:41 bar > > DES > -- > Dag-Erling Smorgrav - [EMAIL PROTECTED] > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 'rm' incompatibility with Posix.2
> Bogdan TARU <[EMAIL PROTECTED]> writes: > > On 10 Apr 2002, Dag-Erling Smorgrav wrote: > > > In my humble opinion, Solaris (and every other *nix) is broken in this > > > respect, and *BSD is correct. > > Except for OpenBDS. No NetBDS machine available, maybe some of you could > > try it on one as well? > > I don't know of any "OpenBDS" or "NetBDS", but NetBSD has the same > semantics as FreeBSD: > > des@rc4 ~% mkdir foo > des@rc4 ~% touch foo/bar > des@rc4 ~% ln -s foo baz > des@rc4 ~% ls -l baz > lrwxr-xr-x 1 des des 3 Apr 10 16:41 baz@ -> foo > des@rc4 ~% ls -l baz/ > total 0 > -rw-r--r-- 1 des des 0 Apr 10 16:41 bar OpenBSD is the same. > DES > -- > Dag-Erling Smorgrav - [EMAIL PROTECTED] -- Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]> http://www.freebsd-services.com/ Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 'rm' incompatibility with Posix.2
Bogdan TARU <[EMAIL PROTECTED]> writes: > On 10 Apr 2002, Dag-Erling Smorgrav wrote: > > In my humble opinion, Solaris (and every other *nix) is broken in this > > respect, and *BSD is correct. > Except for OpenBDS. No NetBDS machine available, maybe some of you could > try it on one as well? I don't know of any "OpenBDS" or "NetBDS", but NetBSD has the same semantics as FreeBSD: des@rc4 ~% mkdir foo des@rc4 ~% touch foo/bar des@rc4 ~% ln -s foo baz des@rc4 ~% ls -l baz lrwxr-xr-x 1 des des 3 Apr 10 16:41 baz@ -> foo des@rc4 ~% ls -l baz/ total 0 -rw-r--r-- 1 des des 0 Apr 10 16:41 bar DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 'rm' incompatibility with Posix.2
On 10 Apr 2002, Dag-Erling Smorgrav wrote: > Bogdan TARU <[EMAIL PROTECTED]> writes: > > I have attached a patch for the 'rm' untility, which strips the trailing > > slash(es) from the path (according to Posix.2). But I think there are many > > other utilities which need to be patched (e.g. cp, mv). > > Please don't. This functionality is extremely useful. Consider this: > > des@des ~% mkdir foo > des@des ~% touch foo/bar > des@des ~% ln -s foo baz > des@des ~% ls -l baz > lrwxr-xr-x 1 des des 3 Apr 10 16:15 baz -> foo > des@des ~% ls -l baz/ > total 0 > -rw-r--r-- 1 des des 0 Apr 10 16:15 bar > > and the same scenario on Solaris: > > des@sex ~% mkdir foo > des@sex ~% touch foo/bar > des@sex ~% ln -s foo baz > des@sex ~% ls -l baz > lrwxrwxrwx 1 des des3 Apr 10 16:16 baz -> foo/ > des@sex ~% ls -l baz/ > lrwxrwxrwx 1 des des3 Apr 10 16:16 baz/ -> foo/ > [scream and curse] > des@sex ~% cd baz > des@sex ~/baz% ls -l > total 0 > -rw--- 1 des des0 Apr 10 16:16 bar > > In my humble opinion, Solaris (and every other *nix) is broken in this > respect, and *BSD is correct. Except for OpenBDS. No NetBDS machine available, maybe some of you could try it on one as well? bogdan > > DES > -- > Dag-Erling Smorgrav - [EMAIL PROTECTED] > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 'rm' incompatibility with Posix.2
Bogdan TARU <[EMAIL PROTECTED]> writes: > I have attached a patch for the 'rm' untility, which strips the trailing > slash(es) from the path (according to Posix.2). But I think there are many > other utilities which need to be patched (e.g. cp, mv). Please don't. This functionality is extremely useful. Consider this: des@des ~% mkdir foo des@des ~% touch foo/bar des@des ~% ln -s foo baz des@des ~% ls -l baz lrwxr-xr-x 1 des des 3 Apr 10 16:15 baz -> foo des@des ~% ls -l baz/ total 0 -rw-r--r-- 1 des des 0 Apr 10 16:15 bar and the same scenario on Solaris: des@sex ~% mkdir foo des@sex ~% touch foo/bar des@sex ~% ln -s foo baz des@sex ~% ls -l baz lrwxrwxrwx 1 des des3 Apr 10 16:16 baz -> foo/ des@sex ~% ls -l baz/ lrwxrwxrwx 1 des des3 Apr 10 16:16 baz/ -> foo/ [scream and curse] des@sex ~% cd baz des@sex ~/baz% ls -l total 0 -rw--- 1 des des0 Apr 10 16:16 bar In my humble opinion, Solaris (and every other *nix) is broken in this respect, and *BSD is correct. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 'rm' incompatibility with Posix.2
On Wednesday 10 April 2002 04:45 am, Bogdan TARU wrote: | Dear Rogier & Terry, | | I didn't say the behaviour contradicts Posix.2. I just said that Posix.2 | specifies removal of the trailing slashes when doing directory operation. I don't think I follow the distinction here. If posix requires removal of the trailing slashes on directory operations, and it is your perception that FreeBSD does not do this, then it seems to me that you *are* saying the FreeBSd contradicts Posix.2. Aren't you? I mean, isn't that the complaint? That said, what you've cited isn't a case of a directory operation; it's a case of a symbolic-link operation. Does Posix.2 say anything one way or another about those? In other words, what you are describing here (behavior of which I was utterly unaware, but now that I am I certainly hope it doesn't change because it seems quite convenient) is the following algorithm used by FreeBSD: If there is a symbolic link with a trailing /, then resolve the symbolic link into the target. I don't think it's resolving it into "the target with a trailing slash"; thus, with mkdir dir ln -s dir link rm -r link/ is the same as rm -r dir But the posix rule you cited doesn't seem to me to have anything to do with this case; rather it merely says that rm -r dir/ is the same as rm -r dir It is of entirely possible that posix2 (which I've never even glanced at) has some *other* rule that implies that the FreeBSD behavior is nonconforming, but this rule doesn't seem to me to be applicable to this case. | Which, for example, freebsd 'rm' does not, which leads to a strange | behaviour. As I stated, I have tryied this on more than one other OS | (OpenBSD 2.9, 3.0, Linux, HP UX 10.20, Solaris 2.7, 2.8), and all yelded | the same result (different from the FreeBSD). | | Also, I quote from the FreeBSD man page of 'rm': | | "The rm utility removes symbolic links, not the files referenced by | the links." | | Greetings, | bogdan | | On Wed, 10 Apr 2002, Rogier R. Mulhuijzen wrote: | > > I have attached a patch for the 'rm' untility, which strips the | > > trailing slash(es) from the path (according to Posix.2). But I think | > > there are many other utilities which need to be patched (e.g. cp, mv). | > | > Can you point out how the behavior violates POSIX.2? | > | > Doc | | To Unsubscribe: send mail to [EMAIL PROTECTED] | with "unsubscribe freebsd-hackers" in the body of the message -- Brian T. Schellenberger . . . . . . . [EMAIL PROTECTED] (work) Brian, the man from Babble-On . . . . [EMAIL PROTECTED] (personal) ME --> http://www.babbleon.org http://www.eff.org <-- GOOD GUYS --> http://www.programming-freedom.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 'rm' incompatibility with Posix.2
Bogdan TARU wrote: > I didn't say the behaviour contradicts Posix.2. I just said that Posix.2 > specifies removal of the trailing slashes when doing directory operation. Path component operations are a mixed bag. They can occur partially in user space, or they can occur in the kernel. When you refer to a specific object by Name, you are referring to the object. So if we create a sitaution: cd /tmp mkdir tmp cd tmp rimmer# cd /tmp mkdir p ln -s p q and examine what we have, we see: ls -ldi p q p/ q/ 170 drwxr-xr-x 2 root wheel 512 Apr 10 04:03 p 170 drwxr-xr-x 2 root wheel 512 Apr 10 04:03 p/ 43223 lrwxr-xr-x 1 root wheel1 Apr 10 04:03 q -> p 170 drwxr-xr-x 2 root wheel 512 Apr 10 04:03 q/ Let's try your operation: rm -rf q/ ls -ldi p q p/ q/ ls: p: No such file or directory ls: p/: No such file or directory ls: q/: No such file or directory 43223 lrwxr-xr-x 1 root wheel 1 Apr 10 04:03 q -> p Let's undo this: mkdir p ls -ldi p q p/ q/ 170 drwxr-xr-x 2 root wheel 512 Apr 10 04:04 p 170 drwxr-xr-x 2 root wheel 512 Apr 10 04:04 p/ 43223 lrwxr-xr-x 1 root wheel1 Apr 10 04:03 q -> p 170 drwxr-xr-x 2 root wheel 512 Apr 10 04:04 q/ And try without teh trailing "/": rm q ls -ldi p q p/ q/ ls: q: No such file or directory ls: q/: No such file or directory 170 drwxr-xr-x 2 root wheel 512 Apr 10 04:04 p 170 drwxr-xr-x 2 root wheel 512 Apr 10 04:04 p/ > Which, for example, freebsd 'rm' does not, which leads to a strange > behaviour. As I stated, I have tryied this on more than one other OS > (OpenBSD 2.9, 3.0, Linux, HP UX 10.20, Solaris 2.7, 2.8), and all yelded > the same result (different from the FreeBSD). Try the "ls -ldi" example I gave, as well. If POSIX states the trailing slash should be removed (please provide references), then it will make listing the contents of a directory pointed to by a symbolic link impossible, without an explicit reference, e.g.: ln -s p q ls -lai p q q/ 43223 lrwxr-xr-x 1 root wheel 1 Apr 10 04:09 q -> p p: total 5 170 drwxr-xr-x 2 root wheel 512 Apr 10 04:04 . 43089 drwxrwxrwt 5 root wheel 4096 Apr 10 04:09 .. q/: total 5 170 drwxr-xr-x 2 root wheel 512 Apr 10 04:04 . 43089 drwxrwxrwt 5 root wheel 4096 Apr 10 04:09 .. 43089 drwxrwxrwt 5 root wheel 4096 Apr 10 04:09 .. rimmer# ... though it *does* look like the "total" calculation is broken. 8-). > Also, I quote from the FreeBSD man page of 'rm': > > "The rm utility removes symbolic links, not the files referenced by > the links." Only when you give them the symbolic link as the argument. If you add the trailing "/" to "q", you are saying "the directory q or the directory pointed to by the symbolic link q". Consider the case of trying to list "the contents of the directory pointed to by the symbolic link q". You can do this, but it's a bit awkward: ls -lai q/. total 5 170 drwxr-xr-x 2 root wheel 512 Apr 10 04:04 . 43089 drwxrwxrwt 5 root wheel 4096 Apr 10 04:09 .. But... the same can not be done on a remove: rm -rf q/. rm: "." and ".." may not be removed It seems to me that making your change means that ls is also broken, and that making the change to ls is wrong. It also seems to me that making the change universally breaks the operation on the target of a symbolic link. I don't see how you can reconcile the operation of "ls" with your proposed operation for "rm". -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 'rm' incompatibility with Posix.2
On Wed, Apr 10, 2002 at 10:45:25AM +0200, Bogdan TARU wrote: > > Dear Rogier & Terry, > > I didn't say the behaviour contradicts Posix.2. I just said that Posix.2 > specifies removal of the trailing slashes when doing directory operation. > Which, for example, freebsd 'rm' does not, which leads to a strange > behaviour. As I stated, I have tryied this on more than one other OS > (OpenBSD 2.9, 3.0, Linux, HP UX 10.20, Solaris 2.7, 2.8), and all yelded > the same result (different from the FreeBSD). > > Also, I quote from the FreeBSD man page of 'rm': > > "The rm utility removes symbolic links, not the files referenced by > the links." I can't see the point where it is wrong. You aren't referencing a link. And why should rm behave differently than e.g. ls? If I add a trailing '/' I would expect every command to do the same. Well if your are working on differenet systems you should add '/.' to be shure and forget about the '/' only case. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 'rm' incompatibility with Posix.2
Dear Rogier & Terry, I didn't say the behaviour contradicts Posix.2. I just said that Posix.2 specifies removal of the trailing slashes when doing directory operation. Which, for example, freebsd 'rm' does not, which leads to a strange behaviour. As I stated, I have tryied this on more than one other OS (OpenBSD 2.9, 3.0, Linux, HP UX 10.20, Solaris 2.7, 2.8), and all yelded the same result (different from the FreeBSD). Also, I quote from the FreeBSD man page of 'rm': "The rm utility removes symbolic links, not the files referenced by the links." Greetings, bogdan On Wed, 10 Apr 2002, Rogier R. Mulhuijzen wrote: > > > I have attached a patch for the 'rm' untility, which strips the trailing > >slash(es) from the path (according to Posix.2). But I think there are many > >other utilities which need to be patched (e.g. cp, mv). > > Can you point out how the behavior violates POSIX.2? > > Doc > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 'rm' incompatibility with Posix.2
> I have attached a patch for the 'rm' untility, which strips the trailing >slash(es) from the path (according to Posix.2). But I think there are many >other utilities which need to be patched (e.g. cp, mv). Can you point out how the behavior violates POSIX.2? Doc To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 'rm' incompatibility with Posix.2
Bogdan TARU wrote: > As you can see, when I tried to remove the symlink 'b' with a trailing > slash 'rm -rf b/', the target directory was removed instead of the actual > symlink. Of course, this is weird (tryied it on some other 10 un*xes, and > all worked in another way). > > I have attached a patch for the 'rm' untility, which strips the trailing > slash(es) from the path (according to Posix.2). But I think there are many > other utilities which need to be patched (e.g. cp, mv). The trailing "/" is supposed to be this way. It means "evaluate the preceeding as a directory". This is a kernel thing: it's what makes "ls -l symlink-to-dir" show the symlink, and "ls -l symlink-to-dir/" show the contents of the directory pointed to by the symlink). You will also notice that when you are tab-expanding a symlink to a directory in tcsh (now csh), that it automatically adds the trailing "/"... in fact, if I had to guess, this is where I would expect that you had seen the behaviour. For a recursive removal of a symlink or a directory containing a symlink, this makes sense, actually, since the idea of recursively removing something you can't recurse into *doesn't* make sense. If you were going to patch this at all, the only thing that *might* make sense is to do an lstat() before deciding to recurse into the thing. Notice that an lstat on "symlink-to-dir/" acts like stat; while without the trailing "/", it does not. This also reinforces the correctness of the behaviour. Are you maybe using an alias which expand to "rm -rf $*"?? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
'rm' incompatibility with Posix.2
Hi everyone, I have noticed quite some time ago a strange way in which some basic FreeBSD utilities work, related to symlinks. Example session: bgd@cvs$ mkdir temp bgd@cvs$ ln -s temp b bgd@cvs$ ls -ald temp b lrwxr-xr-x 1 bgd wheel4 Apr 9 11:27 b -> temp drwxr-xr-x 2 bgd wheel 512 Apr 9 11:27 temp bgd@cvs$ rm -rf b/ bgd@cvs$ ls -ald temp b ls: temp: No such file or directory lrwxr-xr-x 1 bgd wheel 4 Apr 9 11:27 b -> temp bgd@cvs$ As you can see, when I tried to remove the symlink 'b' with a trailing slash 'rm -rf b/', the target directory was removed instead of the actual symlink. Of course, this is weird (tryied it on some other 10 un*xes, and all worked in another way). I have attached a patch for the 'rm' untility, which strips the trailing slash(es) from the path (according to Posix.2). But I think there are many other utilities which need to be patched (e.g. cp, mv). Greetings, bogdan 0a1,2 > > 463,470d464 < /* strip trailing slashes, since POSIX.2 defines basename < as the final portion of a path after the trailing slashes < have been removed. <*/ < p = strrchr (*t, '\0'); < while (--p > *t && *p == '/') <*p = '\0'; <
