The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Rob Pike <robpike@gmail.com>
To: ron minnich <rminnich@gmail.com>
Cc: "bakul@iitbombay.org" <bakul@iitbombay.org>,
	"tuhs@minnie.tuhs.org" <tuhs@minnie.tuhs.org>
Subject: Re: [TUHS] moving directories in svr2
Date: Thu, 30 Dec 2021 07:59:56 +1100	[thread overview]
Message-ID: <CAKzdPgxMk1gcXvCRypvtdGTX__xcM-XxOWf7OuAmQPyzwNgxYw@mail.gmail.com> (raw)
In-Reply-To: <CAP6exYLSubjEw_rx_J0F9rbqkNLd-kC26zB6=cCO4i6bQR_bzg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 4243 bytes --]

Not an answer, but relevant: Apple's Time Machine works by hard-linking
directories to make the forest of old roots.

-rob


On Thu, Dec 30, 2021 at 5:28 AM ron minnich <rminnich@gmail.com> wrote:

> since .. came up, nobody mentioned it yet,
> https://plan9.io/sys/doc/lexnames.pdf
>
> but the subject line is "moving directories" and, as pointed out, on
> old school file systems with hard links, it's not a move, just an ln,
> more or less. And in the easy case, it's easy; and in the not so easy
> case, it can be impossible ...
>
> On newer systems, which don't have such notions as hard links, it's a
> different game, and on many, it may not be possible; dircp to the
> rescue, with all the pain that implies (doesn't go well when you are
> in CA and the server is in NJ, trust me :-)
>
> But this brings up a question I forgot: what was the last Unix version
> that let users make arbitrary links, such that the file system was no
> longer a DAG? I recall in v6 days hearing that earlier Unix allowed
> this, and that cleanup (via icheck and friends) got to be near
> impossible.
>
> On Wed, Dec 29, 2021 at 9:50 AM Brantley Coile <brantley@coraid.com>
> wrote:
> >
> > Plan 9 can't move directories with mv. I will only change the name of
> them.
> > (If this is the question. I was only half paying attention to the
> thread. Sorry)
> >
> >         --bwc
> >
> > cessna% mkdir dira
> > cessna% mkdir dirb
> > cessna% touch dira/a
> > cessna% touch dirb/b
> > cessna% mv dira dirb
> > mv: can't remove ./dirb: remove -- directory not empty
> >
> > To move contents of directories we use dircp.
> >
> > cessna% man dircp
> >
> >      TAR(1)                                                     TAR(1)
> >
> >      NAME
> >           tar, dircp - archiver
> >
> >      SYNOPSIS
> >           tar key [ file ... ]
> >
> >           dircp fromdir todir
> >
> >      DESCRIPTION
> >           Tar saves and restores file trees.  It is most often used to
> >           transport a tree of files from one system to another.  The
> >
> >         ...
> >                and .tz.  If no extension matches, gzip is used.  The z
> >                flag is unnecessary (but allowed) when using the t and
> >                x verbs on archives with recognized extensions.
> >
> >      EXAMPLES
> >           Tar can be used to copy hierarchies thus:
> >
> >                @{cd fromdir && tar c .} | @{cd todir && tar xT}
> >
> >           Dircp does this.
> >
> >      SOURCE
> >           /sys/src/cmd/tar.c
> >           /rc/bin/dircp
> >
> >      SEE ALSO
> >           ar(1), bundle(1), tapefs(4), mkfs(8)
> >
> >
> >
> > cessna%
> > > On Dec 29, 2021, at 12:38 PM, Clem Cole <clemc@ccc.com> wrote:
> > >
> > > At the risk of kicking a dead horse too much ...
> > >
> > > On Wed, Dec 29, 2021 at 12:14 PM <arnold@skeeve.com> wrote:
> > > Plan 9 eventually did something like this. I don't remember the
> details.
> > > Arnold - point taken but ... unfortunately, I think that the
> comparison is a little difficult because Plan9's concepts of namespaces is
> a tad different than UNIX's.  But I'll let Rob or Ken comment as they lived
> and developed both systems.
> > >
> > > FWIW: An object store is something that retains information after the
> processes that operates on it complete - i.e. its a static entity.  Links
> were (are) also a static concept.   Late binding to names (like symlinks)
> are a dynamic (runtime idea).  Bakul points out that by using the per
> process u area, the dynamic context can be retained.  The observation is
> that .. (like symlinks) tend to be a runtime (dynamic) notion, although I'm
> not sure how you keep consistency in the static FS if you don't store the
> link in the inode.  As someone that did, I suggest - try writing fsck if
> you are using dynamic content.   How do you know?  I'd still claim it is
> the same issue.
> > >
> > > Anyway, I suppose that like context sensitive symlinks (which I sorely
> miss), you could do this and keep a list of the N inodes for the N parents
> and then like CDSL's keep the one you used to get there in the u area so
> that .. picks the proper one on the way out and you can still have the
> static notion which something like fsck can check off line.
> >
>

[-- Attachment #2: Type: text/html, Size: 5519 bytes --]

  reply	other threads:[~2021-12-29 21:00 UTC|newest]

Thread overview: 71+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-29 16:59 Bakul Shah
2021-12-29 17:04 ` Clem Cole
2021-12-29 17:14 ` arnold
2021-12-29 17:38   ` Clem Cole
2021-12-29 17:49     ` Brantley Coile
2021-12-29 18:27       ` ron minnich
2021-12-29 20:59         ` Rob Pike [this message]
  -- strict thread matches above, loose matches on Subject: below --
2021-12-30  3:45 Noel Chiappa
2021-12-30  4:02 ` Bakul Shah
2021-12-30 16:40 ` Theodore Ts'o
2021-12-30 22:31   ` Dan Cross
2021-12-31  0:43     ` Bakul Shah
2021-12-31  1:00       ` Rob Pike
2021-12-31  1:45         ` Bakul Shah
2021-12-31  2:23           ` Adam Thornton
2021-12-31 18:56       ` Chet Ramey
2021-12-31  3:08     ` Theodore Ts'o
2021-12-31  3:23       ` Rob Pike
2021-12-31  5:16         ` Theodore Ts'o
2021-12-31  5:21           ` Dan Cross
2021-12-31  5:55           ` Rob Pike
2021-12-31 13:32             ` Michael Kjörling
2021-12-31 15:53               ` Adam Thornton
2021-12-31 16:13                 ` Arthur Krewat
2021-12-31 18:17                 ` Dan Cross
2021-12-31 18:23                   ` Larry McVoy
2021-12-31 18:37                     ` Dan Cross
2021-12-31 18:29                   ` Arthur Krewat
2022-01-01  0:09                   ` Theodore Ts'o
2022-01-03 13:35                     ` Dan Cross
2022-01-03 20:23                       ` Theodore Ts'o
2022-01-03 20:45                         ` Warner Losh
2022-01-03 21:15                         ` Dan Cross
2022-01-03 22:26                           ` Theodore Ts'o
2022-01-03 23:10                             ` Dan Cross
2022-01-04 15:45                             ` Chet Ramey
2022-01-09 19:28                             ` Larry McVoy
2022-01-03 23:21                           ` Doug McIntyre
2022-01-03 23:37                             ` Adam Thornton
2022-01-04 14:49                               ` Stuart Remphrey
2022-01-03 23:44                             ` Larry McVoy
2022-01-03 23:56                               ` Warner Losh
2022-01-04  2:28                               ` Theodore Ts'o
2022-01-04  2:42                                 ` Larry McVoy
2022-01-03 22:57                         ` Phil Budne
2021-12-31  5:12       ` Bakul Shah
2021-12-29 19:33 Noel Chiappa
2021-12-30  3:40 ` Jay Logue via TUHS
2021-12-29 19:13 Douglas McIlroy
2021-12-29 19:37 ` Dan Cross
2021-12-29 20:15   ` Dan Cross
2021-12-29 20:42     ` Richard Salz
2021-12-29 20:58       ` Dan Cross
2021-12-29 21:20         ` Clem Cole
2021-12-30  3:15       ` Bakul Shah
2021-12-29 17:12 Douglas McIlroy
2021-12-29 14:33 Will Senn
2021-12-29 15:02 ` arnold
2021-12-29 15:38   ` Will Senn
2021-12-29 15:44     ` Richard Salz
2021-12-29 16:17       ` Clem Cole
2021-12-29 16:58         ` Richard Salz
2021-12-30  5:14         ` Dan Stromberg
2021-12-30 16:22           ` Clem Cole
2021-12-30 18:02           ` John Cowan
2021-12-30 23:04             ` Richard Salz
2021-12-29 15:17 ` Clem Cole
2021-12-29 15:44   ` Will Senn
2021-12-29 16:10     ` Clem Cole
2021-12-29 16:33       ` Warner Losh
2021-12-29 16:01   ` Bakul Shah

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAKzdPgxMk1gcXvCRypvtdGTX__xcM-XxOWf7OuAmQPyzwNgxYw@mail.gmail.com \
    --to=robpike@gmail.com \
    --cc=bakul@iitbombay.org \
    --cc=rminnich@gmail.com \
    --cc=tuhs@minnie.tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).