ber@enea.UUCP (Bjorn Eriksen) (01/06/85)
It turned out that I didn't create an infinit number of subdirectories
but rather a directory linked to itself, that is in directory A I have
directory B which is a symbolic link to A. As soon as I create a file
in A it will appear in B and B/B and B/B/B ... The odd thing is that B
isn't marked as a symbolic link but as an ordinary directory.
How do I get rid of it?
--
Bjorn Eriksen
ENEA DATA Sweden
UUCP: {decvax,philabs}!mcvax!enea!ber
ARPA: decvax!mcvax!enea!ber@berkeley.arpa
mcvax!enea!ber@seismo.arpajohn@mplvax.UUCP (John McInerney) (01/07/85)
In article <792@enea.UUCP> ber@enea.UUCP (Bjorn Eriksen) writes: >I just used 'patch' on a diff but didn't notice that the diff referred >to subdirectories that I didn't have. Patch creates a subdirectory .orig >and somehow it started to create them recursivly, .orig/.orig/.orig/..., >until I guess a "filname too long" error. The problem is now how do I >get rid of .orig without redo the filesystem? A "rm -rf .orig" fails. >This is 4.2BSD. > >-- > Bjorn Eriksen > ENEA DATA Sweden > > UUCP: {decvax,philabs}!mcvax!enea!ber > ARPA: decvax!mcvax!enea!ber@berkeley.arpa > mcvax!enea!ber@seismo.arpa What I did to get rid of these .orig files was to move the parent directory of the offending .orig calling it "blackhole" and then used tar to move the hierarchy to its correct place (not including the .orig file of course) with commands something like: mkdir gooddir cd blackhole tar cpf - [a-z]* | (cd ../gooddir; tar xpf - ) Then I used the following C program to get rid of the .orig directory. ----------------------------------------------------------------------------- main(){ if (unlink("blackhole/.orig")){ perror("rmblck:"); } } ----------------------------------------------------------------------------- I think that you could directly use the unlink(2) call to remove just the .orig directory, but I was paranoid that I would remove the good stuff too. Also, I believe that there are two occurances of the .orig link to parent in the 4.2 distribution. A find started from root should find them for you; be sure to redirect the error output. John McInerney sdcsvax!mplvax!john UUCP john@nosc ARPA
avolio@grendel.UUCP (Frederick M. Avolio) (01/07/85)
> It turned out that I didn't create an infinit number of subdirectories > but rather a directory linked to itself, that is in directory A I have > directory B which is a symbolic link to A. As soon as I create a file > in A it will appear in B and B/B and B/B/B ... There's a sign-post up ahead... Bjorn Erikson has entered....The Twilight Zone! -- Fred Avolio 301/731-4100 x4227 UUCP: {seismo,decvax}!grendel!avolio ARPA: grendel!avolio@seismo.ARPA
henry@utzoo.UUCP (Henry Spencer) (01/08/85)
> It turned out that I didn't create an infinit number of subdirectories > but rather a directory linked to itself, that is in directory A I have > directory B which is a symbolic link to A. As soon as I create a file > in A it will appear in B and B/B and B/B/B ... Aren't symbolic links delightful? -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
ber@enea.UUCP (Bjorn Eriksen) (01/11/85)
I just used 'patch' on a diff but didn't notice that the diff referred
to subdirectories that I didn't have. Patch creates a subdirectory .orig
and somehow it started to create them recursivly, .orig/.orig/.orig/...,
until I guess a "filname too long" error. The problem is now how do I
get rid of .orig without redo the filesystem? A "rm -rf .orig" fails.
This is 4.2BSD.
--
Bjorn Eriksen
ENEA DATA Sweden
UUCP: {decvax,philabs}!mcvax!enea!ber
ARPA: decvax!mcvax!enea!ber@berkeley.arpa
mcvax!enea!ber@seismo.arpathomas@utah-gr.UUCP (Spencer W. Thomas) (01/12/85)
In article <4883@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >> It turned out that I didn't create an infinit number of subdirectories >> but rather a directory linked to itself, that is in directory A I have >> directory B which is a symbolic link to A. As soon as I create a file >> in A it will appear in B and B/B and B/B/B ... > >Aren't symbolic links delightful? I doubt very much it was a symbolic link - he said it showed up in the 'ls' listing as a real directory. Also, you can easily remove a symbolic link. I think it was a real link (only possible under 4.2 when running as root, and VERY dangerous). Oh - yes, symbolic links are delightful (and not in the sense you meant it, either). =S -- =Spencer ({ihnp4,decvax}!utah-cs!thomas, thomas@utah-cs.ARPA) <<< Silly quote of the week >>>
ellis@spar.UUCP (Michael Ellis) (01/15/85)
From Spencer Thomas: >In article <4883@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >>> It turned out that I didn't create an infinit number of subdirectories >>> but rather a directory linked to itself, that is in directory A I have >>> directory B which is a symbolic link to A. As soon as I create a file >>> in A it will appear in B and B/B and B/B/B ... >> >>Aren't symbolic links delightful? > >I doubt very much it was a symbolic link - he said it showed up in the >'ls' listing as a real directory. Also, you can easily remove a >symbolic link. I think it was a real link (only possible under 4.2 when >running as root, and VERY dangerous). I also accidentally created a HARD link, using patch, that behaved as Henry Spencer's monster. And it wrought havoc with our nightly filesystem maintenance -- guess how long a `find' on the partition containing such a directory will run... Getting rid of the black hole was NOT fun. Assuming Henry's experience was related to mine, I wonder how could patch do such an evil thing? And how can I avoid this in the future, short of removing `patch'? And just how is it possible for `root' to create such a directory in 4.2 without writing to raw disc? -michael
rpw3@redwood.UUCP (Rob Warnock) (01/16/85)
+--------------- | I also accidentally created a HARD link, using patch,... | ... I wonder how could patch do such an evil thing? | And just how is it possible for `root' to create such a directory in 4.2 | without writing to raw disc? | -michael +--------------- WARNING!!! It has ALWAYS been possible (on any UNIX I know) for a superuser to create a (hard) link to a directory. While the "ln" program (command) will not allow it, the system call does (for the superuser) and must (for "mv"). Any program that runs as root and does not use 'system("/bin/ln ...")' for making links (or 'system("mv ...")' for renaming) should have defensive code. (It's actually useful, on occasion, to make a hard link to a directory, to temporarily work around problems with hard-coded paths in binary programs. This is not particularly a problem if you don't create a loop.) Rob Warnock Systems Architecture Consultant UUCP: {ihnp4,ucbvax!dual}!fortune!redwood!rpw3 DDD: (415)572-2607 USPS: 510 Trinidad Lane, Foster City, CA 94404