Monday, 4 March 2013

Re: [gccsdk] unixlib directory iteration doesn't work on Fat32FS

In message <e0d4592753.beeb@ron1954.woosh.co.nz>
Ron <beeb@woosh.co.nz> wrote:

> In message <b1ea532753.Jo@hobbes.bass-software.com>
> John Tytgat <John.Tytgat@aaug.net> wrote:
>
> > In message <f67e522753.beeb@ron1954.woosh.co.nz>
> > Ron <beeb@woosh.co.nz> wrote:
> >
> > > Just my own approach, but I have built a !GCC that doesn't use suffix
> > > swapping and my recent build seems to be working OK.
> > > I also seem to have got away with removing some suffixing routines from
> > > the recipe riscosify.c and unixify.c without side effects this time.
> >
> > Isn't that way too much effort ? Doesn't this work out-of-box with
> > a regular !GCC release where you change UnixEnv$gcc$sfix in !GCC.!Run
> > into an empty string ?
>
> > Afterall, that's the whole point of UnixEnv$*$sfix system variables.
> >
> > John.
>
> Regarding !GCC, the recipe file for gcc has a sfix routine that I had to
> remove also, /only then/ UnixEnv$gcc$sfix "" in the !Run file effects
> the remaining binaries and all is well.

Which "recipe file for gcc" do you mean ?

> So there is a minimum of three changes to do.

Three ? I'm mentioning the UnixEnv$*$sfix @ !Run, you're referring to
a "recipfe file for gcc", but what's the third change ?

> Modifying riscosify.c and unixify.c is extra, but I'm hoping it will make
> them simpler for me to follow for any further changes I might try.
> I still have the problem of textfile,xyz (where xyz is a recogniseable
> extension) causing tar to skip it.
> While it doesn't make much sense to have a file like that on the
> RISC OS filesystem (It should have been already converted by program foo)
> I'm aiming to be able to copy 'all' files verbatim and this is one
> that catches.

If you want to make that bullet proof Unixify should somehow escape the
"," in the RISC OS file name and you have to teach riscosify to do the
unescaping.

BTW, are RISC OS files "/" and "//" properly tar'd and can they be
untar'd on Unix ? :-)

> Setting UnixEnv$prog$sfix to "" is enough to turn off the sfix functioning.
> For programs like tar that are acessing many files, I thought it might
> also be be a speed advantage to remove the sfix /checking/ functions,
> especially as I'm never using them these days.

I would be surprised this having a meaningful advantage.

John.
--
John Tytgat, in his comfy chair at home
John.Tytgat@aaug.net

_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

No comments:

Post a Comment