9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: "Russ Cox" <rsc@swtch.com>
To: 9fans@9fans.net
Subject: Re: [9fans] HFS is a pain in the neck.
Date: Sat, 19 Jul 2008 12:51:27 -0400	[thread overview]
Message-ID: <20080719164849.7C9481E8C6E@holo.morphisms.net> (raw)
In-Reply-To: <f7aa55205f7f4b7036b69d55cbe93553@9srv.net>

Both the vac file format and p9p can handle files
that Plan 9 cannot.  Other than anti-social characters
in file names, they also handle symbolic links.  There are
people who use vac and p9p but have never used Plan 9.
Imposing Plan 9's restrictions on non-Plan 9 users seems odd
and certainly isn't a way to attract users.

When this came up with u9fs, the solution was to treat
u9fs as the boundary between the cleaner Plan 9 world
and the outside world: it's u9fs's responsibility to keep
the bad names out.  Since the vac format already includes
many hooks to represent Unix and MS-DOS and other kinds
of non-Plan 9 file information, I think of vacfs as straddling
the same boundary that u9fs does.

Especially now that there is an unvac, it seems to me that
the right thing to do is make vacfs skip over the paths that
it cannot reliably report back.  The change is minimal: in
vacfs.c:/^vacdirread, in the for loop, add something like

		if(i == 0)
			break;
+		if(isfrogged(vd.elem)){
+			vdcleanup(&vd);
+			continue;
+		}
		n = vacstat(f->file, &vd, (uchar*)p, cnt-nb);

along with a suitable isfrogged() function and a copy of the
isfrog table from the kernel.

If you were feeling more ambitious, you could use the
defrog and enfrog routines from u9fs to translate the
names into Plan 9-acceptable ones.

Russ



  reply	other threads:[~2008-07-19 16:51 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-19 16:25 a
2008-07-19 16:51 ` Russ Cox [this message]
2008-07-20  1:21   ` a

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=20080719164849.7C9481E8C6E@holo.morphisms.net \
    --to=rsc@swtch.com \
    --cc=9fans@9fans.net \
    /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).