[gccsdk] Symlink: Unknown file type

Ron beeb at woosh.co.nz
Thu Mar 17 02:59:18 PDT 2011


In message <55b44eb551.Jo at hobbes.bass-software.com>
          John Tytgat <John.Tytgat at aaug.net> wrote:

> In message <fa9d1eb551.beeb at ron1954.woosh.co.nz>
>           Ron <beeb at woosh.co.nz> wrote:
> 
> > Changing the filetype of the Symlink file to many unheard of
> > types and tar does not ignore them.
> > So I think the error is misleading and tar/unixlib knows what
> > a Symlink file is, and is taking exception to it.
> 
> I'm not familiar with the tar format but I guess that fact that an
> object is a softlink is stored separately (and not part of a RISC OS
> filetype or "," based filetype extension).
> 
> There is support for symbolic links in UnixLib but I don't know how
> well.  At least point 2 of
> <URL:http://www.riscos.info/bugzilla/index.cgi/show_bug.cgi?id=162>
> is still open.
> 
> > Now I have to find if Unixlib is saying 'dont do this'
> > or if Tar is configured to ignore them.
> 
> It would be good if you could further nail down what happens.
> 
> > There was a message from the cross-compiler at one point
> > saying hard links are not supported on your platform.
> 
> Concept of hardlinks does not exist on RISC OS.
> 
> John.

Hi, the exception is caused by tar following links by default.
the tar -h (--dereference) option fixes it. 
So I think everything is working sufficiently well.
Sorry about the red herring, and the "support for symlinks in
Unixlib" explains why tar got RISC OS filetype info at all,
as I dont have __riscosify_control in use yet.

I have been working on a few fronts, and have got an obey file
script that works in place of the suggested sh script for the
naming of multipart archives.
This gets around the 2GB file limit, or could be used to page
RAMdisc sized multiparts
I have had to move on to the latest version 1.26 to get 
multipart archiving to work.
 
Thank you, Ron M.   




More information about the gcc mailing list