bug-xorriso
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-xorriso] bug with handling symbolic links?


From: Joerg Meyer
Subject: Re: [Bug-xorriso] bug with handling symbolic links?
Date: Sat, 21 Feb 2015 13:03:53 +0100

Hi Thomas,

> But it turned out to be quite tricky to chop a
> large Continuation Area of a single file into
> several independent blocks.
> Such large blocks can hardly happen with symbolic links
> but libisofs supports a SUSP protocol AAIP for storing
> extended attributes (man getfattr) and ACLs (man getfacl)
> which might really produce large amounts of SUSP data
> for a single file.
If I understand the bigger picture correctly, I was actually wondering 
why xorriso's SUSP might not potentially have triggered the problem at hands 
even earlier?

> If you are impatient to try the remedy for the symbolic
> link problem, then i can prepare a snapshot tarball.
> But actually the code is not complete and test-worthy
> before i have solved the size problem.
I am rather more curious than impatient and can definitely give it a shot.
Perhaps trying it on my larger "real-world backup case" might lead to some 
useful feedback?
Instead of a tarball, I could also checkout your changes from a {SVN,BZR,git} 
repo
I have checked under
        http://bazaar.launchpad.net/~libburnia-team/libisofs/scdbackup/changes/
but could not yet see your changes there...

Best wishes,
Jörg.


On 21 Feb 2015, at 11:46, Thomas Schmitt <address@hidden> wrote:

> Hi,
> 
> an intermediate update:
> 
> I was able to ensure that the Continuation Area
> of a file begins at a new block, if it does not fit
> entirely into the block that is used for its
> predecessor in the directory.
> My current half-cooked state of libisofs is able
> to make an ISO from your tarball content which
> pleases Linux fs/isofs and isoinfo.
> 
> But it turned out to be quite tricky to chop a
> large Continuation Area of a single file into
> several independent blocks.
> Such large blocks can hardly happen with symbolic links
> but libisofs supports a SUSP protocol AAIP for storing
> extended attributes (man getfattr) and ACLs (man getfacl)
> which might really produce large amounts of SUSP data
> for a single file.
> 
> If you are impatient to try the remedy for the symbolic
> link problem, then i can prepare a snapshot tarball.
> But actually the code is not complete and test-worthy
> before i have solved the size problem.
> 
> 
> Have a nice day :)
> 
> Thomas
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]