From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@9fans.net Subject: Re: [9fans] HFS is a pain in the neck. From: "Russ Cox" Date: Sat, 19 Jul 2008 12:51:27 -0400 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Message-Id: <20080719164849.7C9481E8C6E@holo.morphisms.net> Topicbox-Message-UUID: ecc773c4-ead3-11e9-9d60-3106f5b1d025 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