Re: ooops ! 'ls' & "last modified" column
On 03/26/10 02:37, Olivier Nicole wrote: Hi, I just finished installing FreeBSD on a "machine" whose CMOS time is not set to UTC. The System time is reported correctly (using 'date') but, suprisingly (?), 'ls -la' reports that, among others, the files belonging to "the skeleton" in the user home have been modified... in the future (1 hour later) ! Wait one hour :) I had a stange behaviour with some release of FreeBSD (around 7). We are 7 hours ahead of UTC; after a fresh install I usually do a system upgrade to be sure to be up with every patches. It occured to me a couple of times that the installworld would not work, even though I adjkerntz before. The only way I had was to change the CMOS clock to the local time and change it back to UTC aftergive installing world. Of course, after 7 hours the problem would disappear. Bests, Olivier Hi, Thank you for your interest in my question and related answer :-) I did not have any problem during the installation or the following start-up. I just noticed those "strange" timestamps. But I think that now I understand the behaviour of the installation process (at least in FreeBSD 8.0-Release) as for the timestamps. Basically it is simple: when booting for installation, the system silently (?) thinks the CMOS time is set to UTC and uses the user input for setting _a_ local time. Then it "happens" this local time is the timestamp for _some_ newly created files. After all files have been copied the actual configuration of the clock occurs so that the newly created system will report the correct local time. Later, when the new system boots up, in some cases one can find timestamps in the future for _some_ files and a correct local time. :-) If something (but the local time :-)) is not correct , feel free to send a feedback d ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: ooops ! 'ls' & "last modified" column
Hi, > I just finished installing FreeBSD on a "machine" whose CMOS time is not > set to UTC. > > The System time is reported correctly (using 'date') but, suprisingly > (?), 'ls -la' reports that, among others, the files belonging to "the > skeleton" in the user home have been modified... in the future (1 hour > later) ! Wait one hour :) I had a stange behaviour with some release of FreeBSD (around 7). We are 7 hours ahead of UTC; after a fresh install I usually do a system upgrade to be sure to be up with every patches. It occured to me a couple of times that the installworld would not work, even though I adjkerntz before. The only way I had was to change the CMOS clock to the local time and change it back to UTC after installing world. Of course, after 7 hours the problem would disappear. Bests, Olivier ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Ooops - Re: while I have your attention... Names, copyright and IPv6
> You are responsible for keeping track of the names > under *.example.org, *.example6.org, *.example46.org. > There is no such thing as an IPv6[-only] domain name. > > If you asked about PTR records, this would be more > interesting... [Hint: ip6.arpa.] ;-) The reference is: RFC 3596: DNS Extensions to Support IP Version 6 October 2003. http://www.rfc-editor.org/ -- Cordula's Web. http://www.cordula.ws/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Ooops - Re: while I have your attention... Names, copyright and IPv6
> if I operate a network, boxen1.example.org, boxen2.example.org, etc., as an > IPv4 address space and a second coincident network, boxen1.example6.org, > boxen2.example6.org, etc., as an IPv6 based address space, where does the > authority to allocate the IPv6-network based names reside? AFAIK, there is only one DNS system, which is designed to serve names for both IPv4 and IPv6. It is the client who asks either for A records (IPv4 resolution) or records (IPv6 resolution), from the SAME set of DNS servers. Let's assume that you want to operate *.example.org as IPv4 and *.example6.org as IPv6 networks. You would have two domains in the .org TLD: example.org -> NS ns1.example.org -> NS ns2.example.org example6.org -> NS ns1.example6.org -> NS ns2.example6.org It is important to realize that ns1 and ns2 must resolve to IPv4 addresses for both example.org and example6.org. Now you could populate the DNS maps of ns{1,2}.example6.org with records holding IPv6 addresses, and the DNS maps of ns{1,2}.example.org with A records, holding IPv4 addresses. Nothing prevents you from doing both on the same domain! example46.org -> NS ns1.example46.org NS ns2.example46.org ns{1,2}.example46.org could contain both A and records, like, say: hybrid A hybrid The host hybrid.example46.org would have an IPv4 and an IPv6 address (they don't need to overlap!). Now the clients' resolver library would generally ask for A records, if it should resolve hybrid.example46.org. It would therefore obtain an IPv4 address from ns{1,2}.example46.org for the host name hybrid.example46.org. A client could still ask for IPv6 addresses, e.g.: % host -t hybrid.example46.org (ask for IPv6 address) % host -t a hybrid.example46.org(ask for IPv4 address) % host hybrid.example46.org (same as host -t a ...) > the technical side of it is clear... someone somewhere needs to keep a track > of the names... You are responsible for keeping track of the names under *.example.org, *.example6.org, *.example46.org. There is no such thing as an IPv6[-only] domain name. If you asked about PTR records, this would be more interesting... [Hint: ip6.arpa.] ;-) > anyway, this is straying somewhat from the core subject matter of > this list... Well, yes... -- Cordula's Web. http://www.cordula.ws/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Ooops - Re: while I have your attention... Names, copyright and IPv6
On Mon, 24 Nov 2003 12:43:11 +1100 paul van den bergen <[EMAIL PROTECTED]> granted us these pearls of wisdom: > as usual, there has been a bit of a misunderstanding... being a loosely typed > language, Engliosh is difficult to communicate in :-0 > > Names, addresses and DNS are obviously different things. > > I understand where IPv6 addresses come from (sort of). > I understand (sort of) how IPv6 works for DNS records relating names to IPv6 > addresses > > what I was really asking is: in the IPv4 world, name brokers "sell" names that > are then related to IPv4 addresses. Legality of the name choice etc. is > generally owner onus... Is there a similar sort of (or coincident) naming > authority for IPv6 based names? > > example. > > if I operate a network, boxen1.example.org, boxen2.example.org, etc., as an > IPv4 address space and a second coincident network, boxen1.example6.org, > boxen2.example6.org, etc., as an IPv6 based address space, where does the > authority to allocate the IPv6-network based names reside? > > the technical side of it is clear... someone somewhere needs to keep a track > of the names... > > anyway, this is straying somewhat from the core subject matter of this list... > > > On Mon, 24 Nov 2003 11:30 am, Cordula's Web wrote: > > > how does this all work under IPv6? is the IPv6 domain name allocation as > > > fully fledged as teh IPv4 services? I.e. are there and what are the > > > restrictions on who can set up a name broker service for IPv6? what are > > > the likely gottchas? > > > > I don't know for sure here, so please take this with a grain of salt: > > > > IPv6 addresses are represented by instead of A records in > > DNS nameservers. Right now, I think that you can only point > > .org (and other [cc]TLD) nameservers to nameservers residing > > on an IPv4 address [anyone correct me if I'm wrong here]. > > But you could always configure your nameservers (let's say > > ns1.bergen.org, ns2.bergen.org) to return IPv6 addresses > > to some names, by adding records to them. > > > > But since IPv6 names are not (yet) globally routed on the Internet, > > this will have local meaning only (e.g. on an intranet). > > > > Generally speaking: IPv4 and IPv6 addresses are _never_ > > allocated by name brokers or DNS systems. They reside at > > a much lower level, which has nothing to do with _names_. > > If you connect to the Internet, your upstream provider(s) > > will assign to you IPv4 address blocks automatically. > > You would normally not be able to influence this, because > > it is deeply intertwined with the routing protocols that > > all network operators use to transmit data on the Internet. > > > > You may ask how network operators get their IP address > > blocks. Check out IANA: http://www.iana.org/ especially: > > http://www.iana.org/ipaddress/ip-addresses.htm > AFAIK domain names have little to do with your choice of IPV4 or IPV6. There can be only one registered owner of any given domain name and that domain name space could be either v4 or v6 at the discretion of the owner. LukeK ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Ooops - Re: while I have your attention... Names, copyright and IPv6
as usual, there has been a bit of a misunderstanding... being a loosely typed language, Engliosh is difficult to communicate in :-0 Names, addresses and DNS are obviously different things. I understand where IPv6 addresses come from (sort of). I understand (sort of) how IPv6 works for DNS records relating names to IPv6 addresses what I was really asking is: in the IPv4 world, name brokers "sell" names that are then related to IPv4 addresses. Legality of the name choice etc. is generally owner onus... Is there a similar sort of (or coincident) naming authority for IPv6 based names? example. if I operate a network, boxen1.example.org, boxen2.example.org, etc., as an IPv4 address space and a second coincident network, boxen1.example6.org, boxen2.example6.org, etc., as an IPv6 based address space, where does the authority to allocate the IPv6-network based names reside? the technical side of it is clear... someone somewhere needs to keep a track of the names... anyway, this is straying somewhat from the core subject matter of this list... On Mon, 24 Nov 2003 11:30 am, Cordula's Web wrote: > > how does this all work under IPv6? is the IPv6 domain name allocation as > > fully fledged as teh IPv4 services? I.e. are there and what are the > > restrictions on who can set up a name broker service for IPv6? what are > > the likely gottchas? > > I don't know for sure here, so please take this with a grain of salt: > > IPv6 addresses are represented by instead of A records in > DNS nameservers. Right now, I think that you can only point > .org (and other [cc]TLD) nameservers to nameservers residing > on an IPv4 address [anyone correct me if I'm wrong here]. > But you could always configure your nameservers (let's say > ns1.bergen.org, ns2.bergen.org) to return IPv6 addresses > to some names, by adding records to them. > > But since IPv6 names are not (yet) globally routed on the Internet, > this will have local meaning only (e.g. on an intranet). > > Generally speaking: IPv4 and IPv6 addresses are _never_ > allocated by name brokers or DNS systems. They reside at > a much lower level, which has nothing to do with _names_. > If you connect to the Internet, your upstream provider(s) > will assign to you IPv4 address blocks automatically. > You would normally not be able to influence this, because > it is deeply intertwined with the routing protocols that > all network operators use to transmit data on the Internet. > > You may ask how network operators get their IP address > blocks. Check out IANA: http://www.iana.org/ especially: > http://www.iana.org/ipaddress/ip-addresses.htm -- Dr Paul van den Bergen Centre for Advanced Internet Architectures caia.swin.edu.au [EMAIL PROTECTED] IM:bulwynkl2002 "And some run up hill and down dale, knapping the chucky stones to pieces wi' hammers, like so many road makers run daft. They say it is to see how the world was made." Sir Walter Scott, St. Ronan's Well 1824 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Ooops - Re: while I have your attention... Names, copyright and IPv6
paul van den bergen wrote: Ooops... I forgot the most important part of my question... IPv6 how does this all work under IPv6? is the IPv6 domain name allocation as fully fledged as teh IPv4 services? I.e. are there and what are the restrictions on who can set up a name broker service for IPv6? what are the likely gottchas? Paul- AFAIK, IPv6 is in fact enabled/capable in BIND currently, but no one uses it- IPv6 will be a LONG time in coming to everyone, with the major challenge being a 'transition phase' where devices (routers for a prime example) are able to handle both ipv4 and ipv6...without that, ipv6 is useless outside of 'playing with it locally.' This shouldn't have any effect on name registrations, they will just eventually map to both ipv4 AND ipv6 addresses.. Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Ooops.
On Sun, Feb 02, 2003 at 05:39:09PM +1030, [EMAIL PROTECTED] wrote: > The command I used to copy was: > dump 0af - / | restore xf - > Is it dump or restore that have been causing the problem? Shouldn't that be: dump 0af - / | restore rf - ? Jeff To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
Re: Ooops.
On Sun, Feb 02, 2003 at 05:39:09PM +1030, [EMAIL PROTECTED] typed: > Are we aiming at the wrong target, here? > I used the fixit CD to examine ad0s3, where my missing files reside. > > What I found was that (eg) /bin, /etc, /dev were full of files/directories, but > /var and /usr were empty. I didn't ask dump/restore to delete anything, and did > not ask rm to remove the files from /var or /usr/everything. > The command I used to copy was: > dump 0af - / | restore xf - > Is it dump or restore that have been causing the problem? This is not a problem. dump works one filesystem at a time and it looks like you have /usr and /var mounted on seperate filesystems. So, the commands to copy everything are: cd /mnt/other dump 0af - / | restore xf - cd /mnt/other/var dump 0af - /var | restore xf - cd /mnt/other/usr dump 0af - /usr | restore xf - > > home@ on ad0s3 still links to /usr/home so that if I "mount /dev/ad0s3 > /mnt/other" in my working system on ad2, ls /mnt/other/home shows my working > home directory - a bit startling when you first see it. Don't see this as > significant, but you gurus might. > > -- > Brian > > > --- > This message sent through Adam Internet Webmail > http://www.adam.com.au > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-questions" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
Re: Ooops.
Are we aiming at the wrong target, here? I used the fixit CD to examine ad0s3, where my missing files reside. What I found was that (eg) /bin, /etc, /dev were full of files/directories, but /var and /usr were empty. I didn't ask dump/restore to delete anything, and did not ask rm to remove the files from /var or /usr/everything. The command I used to copy was: dump 0af - / | restore xf - Is it dump or restore that have been causing the problem? home@ on ad0s3 still links to /usr/home so that if I "mount /dev/ad0s3 /mnt/other" in my working system on ad2, ls /mnt/other/home shows my working home directory - a bit startling when you first see it. Don't see this as significant, but you gurus might. -- Brian --- This message sent through Adam Internet Webmail http://www.adam.com.au To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
Re: Ooops
Hi again all, I am having reverse DNS issues so I am posting from another server. I am astounded at the bandwidth created by my little oops. Something that does make some sence to me is the . and .. directories. that had never occured to me. Anyways, the commands I used are quite fresh in my mind as I was taking my time ensuring I would not do exactly what I did :-( cd / mount /dev/da1s1a /mnt mount /dev/da1s1g /mnt/var mount /dev/da1s1e /mnt/usr ... cd /mnt cd /mnt cwd (server shows /mnt) rm -rf * Ooops! I have since been to the terminal, both drives are shiny clean. The good news is this was a brand new server, not in production. Anyone want to talk off-list about rDNS? -Grant Grant W. Peel Server Admin [EMAIL PROTECTED] http://thenetnow.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
Re: Ooops.
On 2003-02-01 20:53, [EMAIL PROTECTED] wrote: > Quoting Bill Moran <[EMAIL PROTECTED]>: > > I've been quietly following this thread since it started and ... > > I can't reproduce this behaviour. I've created and deleted I > > don't know how many test directories and symlinks and I can't get > > it to do what you're claiming it did. > > As root, try copying directory from one disk to another, then rm -rf > directory from the copy. That seems to be what the two recent > examples have in common. I have tried various combinations of ln(1) and rm(1) since the thread started, and I am sure that there are only two cases where rm deletes things that the user probably didn't want to remove. a. Errors in filename completion. b. Adding a slash (/) character at the end of the link name. == Case A == When completing filenames that start with `.', the Unix shells that I have tried (/bin/sh and tcsh from the base system, and GNU bash2), will also match the `..' hard link to the parent directory. This is dangerous in combination with the -r flag, since rm(1) has no way of knowing that you don't want to recursively remove the parent directory and merrily hops along, deleting many more files than the ones you probably meant, when commands like this are used: # cd /tmp # rm -fr .* I usually get around this foot shooting possibility by avoiding to delete dotfiles with .* and using the more elaborate, but a lot safer, pattern .[^.]* to match them: # cd /tmp # rm -fr .[^.]* This makes sure that rm(1) never gets the `..' filename as an argument and the -r option can't turn around and bite me deleting all the files on my disk. This will also inhibit rm(1) from deleting files named with funny patterns like `...hahaha...i.h4x0red.you' so some amount of care is still required. But deleting less files than necessary is something I can cope with. Deleting more files than I asked is something that I always try to avoid :-) == Case B == * Note: When a symlink is suffixed with a slash character, then many commands that use the fts_xxx() functions in a FreeBSD system will operate on the *target* of the symlink instead of the symlink itself. This is clearly apparent in the sample session below: $ cd /tmp/ $ mkdir test $ cd test $ mkdir alpha $ touch alpha/foo $ ln -s alpha beta $ ls -l total 2 drwxrwxr-x 2 giorgos wheel - 512 Feb 1 17:56 alpha lrwxrwxr-x 1 giorgos wheel - 5 Feb 1 17:56 beta -> alpha $ ls -l beta lrwxrwxr-x 1 giorgos wheel - 5 Feb 1 17:56 beta -> alpha $ ls -l beta/ total 0 -rw-rw-r-- 1 giorgos wheel - 0 Feb 1 17:56 foo $ rm -fr beta/ $ ls -l total 0 lrwxrwxr-x 1 giorgos wheel - 5 Feb 1 17:56 beta -> alpha $ Note how the last directory listing has beta, still pointing to a non-existent alpha directory. By calling rm(1) on `beta/' (including the final slash character) I have explicitly asked that the target of the link is removed. The link remains, but alpha is deleted. > The only difference between the two experiences is that I was able > to remove (eg) the copied bin directory without affecting the > original, but suffered when trying to remove the copied home > directory. I assumed (perhaps incorrectly) that the symlink > attached to home was the cause. Without having the exact set of commands that you have used, I can't tell for sure what happened. There are only two cases where the behavior of commands operating on symlinks might come as a surprise to the unwary user. Those that I have listed above. I cannot guess which one of the two bit you and which one bit the original poster of this thread, without having access to detailed command history though. > Yes - use tcsh as root. It's not a matter of the shell. It is a matter of what the arguments of rm(1) are, when it's used though. > Unfortunately the history only goes so far back and lots has > happened since. Sorry. However, I'd be prepared to swear on a > (small) stack of bibles that the command I issued was: > rm -rf home I don't know about swearing, but try as I might I can't get rm(1) to delete the target of a symlink calling it this way. Add an extra slash character at the end of that and we're back in territorry that I can recognise, understand and explain :-) > This removed /slash/var/home from /dev/ad2 as I wished, but also > removed the original /usr/home on /dev/ad0. I had RTFM because I > knew rm was very powerful and that undeletion was "impossible". > -rf is all that is required to delete a directory and any > subdirectories therein, is it not? Yes it is. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
Re: Ooops.
Quoting Bill Moran <[EMAIL PROTECTED]>: > I've been quietly following this thread since it started and ... > I can't reproduce this behaviour. I've created and deleted I don't > know how many test directories and symlinks and I can't get it to > do what you're claiming it did. As root, try copying directory from one disk to another, then rm -rf directory from the copy. That seems to be what the two recent examples have in common. The only difference between the two experiences is that I was able to remove (eg) the copied bin directory without affecting the original, but suffered when trying to remove the copied home directory. I assumed (perhaps incorrectly) that the symlink attached to home was the cause. > He's absolutely correct. Without the _exact_ command that you used, > it's going to be very hard to figure out what went wrong. > Are you using a shell that keeps a command history (i.e. bash)? If > so, can you get us the exact command that you issued? Yes - use tcsh as root. Unfortunately the history only goes so far back and lots has happened since. Sorry. However, I'd be prepared to swear on a (small) stack of bibles that the command I issued was: rm -rf home This removed /slash/var/home from /dev/ad2 as I wished, but also removed the original /usr/home on /dev/ad0. I had RTFM because I knew rm was very powerful and that undeletion was "impossible". -rf is all that is required to delete a directory and any subdirectories therein, is it not? -- Brian --- This message sent through Adam Internet Webmail http://www.adam.com.au To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
Re: Ooops.
Giorgos Keramidas wrote: Unfortunately, rm -rf home removed home from the source /usr directory as well! :-( I presume that this was due to /home being a symlink to /usr/home, and somehow that link remained, so that -r referred to everything below the symlink as well as to the directory I was trying to remove. Whatever the explanation, IMHO rm -r should NOT do this by default. As far as I know, it doesn't. You should show use a minimal set of commands that reproduces the bug. This will help anyone with a bit of C knowledge to track it down in the rm(1) source and fix it. I've been quietly following this thread since it started and ... I can't reproduce this behaviour. I've created and deleted I don't know how many test directories and symlinks and I can't get it to do what you're claiming it did. He's absolutely correct. Without the _exact_ command that you used, it's going to be very hard to figure out what went wrong. Are you using a shell that keeps a command history (i.e. bash)? If so, can you get us the exact command that you issued? -- Bill Moran Potential Technologies http://www.potentialtech.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
Re: Ooops.
On 2003-01-31 13:56, [EMAIL PROTECTED] wrote: > Quoting Lowell Gilbert <[EMAIL PROTECTED]>: > > [EMAIL PROTECTED] writes: > > Can you explain what you think is a problem? > > Well - it's happened to two uf us in the past month! In both cases > the operator was copying files from one drive to another and wished > to delete files from the second drive on which the copy resided. > In both cases rm -rf removed both copy AND source! :-( You should keep a log of the commands (if possible) when things like this happen. It was probably caused by trying to `rm -fr .*' which will match all the .dotfiles in the current directory, but will also match `..', the hard link to the parent directory. This is a very easy way to delete recursively everything on the current installation when it happens in /home or /usr or other filesystems directly mounted under /, the root filesystem. > Unfortunately, rm -rf home removed home from the source /usr > directory as well! :-( I presume that this was due to /home being > a symlink to /usr/home, and somehow that link remained, so that -r > referred to everything below the symlink as well as to the directory > I was trying to remove. > > Whatever the explanation, IMHO rm -r should NOT do this by default. As far as I know, it doesn't. You should show use a minimal set of commands that reproduces the bug. This will help anyone with a bit of C knowledge to track it down in the rm(1) source and fix it. - Giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
Re: Ooops.
On Fri, Jan 31, 2003 at 01:56:54PM +1030, [EMAIL PROTECTED] typed: > Quoting Lowell Gilbert <[EMAIL PROTECTED]>: > > > [EMAIL PROTECTED] writes: > > Can you explain what you think is a problem? > > Well - it's happened to two uf us in the past month! > In both cases the operator was copying files from one drive to another and > wished to delete files from the second drive on which the copy resided. In > both cases rm -rf removed both copy AND source! :-( > > In my case I was setting up a larger hard drive from a smaller one using > dump/restore, partition by partition. I had just completed copying one smallish > partition and began copying the next, larger partition having forgotten to > change directories. Naturally I soon ran out of room. ("Bother", said Pooh). > No problem, I'll delete the wrongly copied directories from that smaller > partition, move to the larger one, and try again. Unfortunately, rm -rf home > removed home from the source /usr directory as well! :-( I presume that this > was due to /home being a symlink to /usr/home, and somehow that link remained, > so that -r referred to everything below the symlink as well as to the directory > I was trying to remove. > > Whatever the explanation, IMHO rm -r should NOT do this by default. The manpage rm(1) says: The rm utility removes symbolic links, not the files referenced by the links. So what you describe shouldn't have happened. There is one case where removing symlinks can be confusing: rm -rf /home# removes only the symbolic link rm -rf /home/ # removes directory tree /home is linked to So what were the exact commands you issued? > > -- > Brian > > > > --- > This message sent through Adam Internet Webmail > http://www.adam.com.au > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-questions" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
Re: Ooops.
Quoting Lowell Gilbert <[EMAIL PROTECTED]>: > [EMAIL PROTECTED] writes: > Can you explain what you think is a problem? Well - it's happened to two uf us in the past month! In both cases the operator was copying files from one drive to another and wished to delete files from the second drive on which the copy resided. In both cases rm -rf removed both copy AND source! :-( In my case I was setting up a larger hard drive from a smaller one using dump/restore, partition by partition. I had just completed copying one smallish partition and began copying the next, larger partition having forgotten to change directories. Naturally I soon ran out of room. ("Bother", said Pooh). No problem, I'll delete the wrongly copied directories from that smaller partition, move to the larger one, and try again. Unfortunately, rm -rf home removed home from the source /usr directory as well! :-( I presume that this was due to /home being a symlink to /usr/home, and somehow that link remained, so that -r referred to everything below the symlink as well as to the directory I was trying to remove. Whatever the explanation, IMHO rm -r should NOT do this by default. -- Brian --- This message sent through Adam Internet Webmail http://www.adam.com.au To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
Re: Ooops.
[EMAIL PROTECTED] writes: > rm will, unless specifically denied (I THINK you can do that), also follow symlinks. > In my case I was copying files from one HD to another, put one in the wrong > place, and deleted it using rm -rf , only to find that it deleted the original > as well! :-( Eh? > PS I think rm needs looking at so it defaults to NOT deleting copy AND source by > default. [502] (be-well) lowell> mkdir temp [503] (be-well) lowell> cd temp [504] (be-well) temp> mkdir a b [505] (be-well) temp> touch a/foo [506] (be-well) temp> ln -s a/foo b/baz [507] (be-well) temp> ls -l a b a: total 0 -rw-r--r-- 1 lowell lowell 0 Jan 30 22:05 foo b: total 0 lrwxr-xr-x 1 lowell lowell 5 Jan 30 22:05 baz@ -> a/foo [508] (be-well) temp> rm -rf b [509] (be-well) temp> ls -l * total 0 -rw-r--r-- 1 lowell lowell 0 Jan 30 22:05 foo [510] (be-well) temp> Can you explain what you think is a problem? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
Re: Ooops.
Quoting Grant Peel <[EMAIL PROTECTED]>: > Hi all, > > Two hard drives. > > da0s1 > da1s1 > > da0 is primary boot and OS drive. > > da1 is a mirror drive. > > da1's filesystems are mounted on /mnt. > > Silly me runs a rm -rf * while in /mnt . > > Next thing I know EVERYTHING is gone. > > What did I miss here? Been there - done that! :-( rm will, unless specifically denied (I THINK you can do that), also follow symlinks. In my case I was copying files from one HD to another, put one in the wrong place, and deleted it using rm -rf , only to find that it deleted the original as well! :-( I'm looking at two possible undelete options. ffsrecov (in ports) and recover ftp://gatekeeper.dec.com/pub/sysadm/recover.tar.Z One of them might work for you. PS I think rm needs looking at so it defaults to NOT deleting copy AND source by default. -- Brian > > -Grant > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-questions" in the body of the message > --- This message sent through Adam Internet Webmail http://www.adam.com.au To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message