[coaster-devel] Re: [Libburn] a question about file attributes

[Sean Harshbarger]

On Tue, 2004-05-25 at 23:04, Derek Foreman wrote:
> I've added the coaster list to the CC in case they've got any objections.

None here.

> Hopefully it's not too OT. :)
> 
> On Wed, 19 May 2004, Todd Kulesza wrote:
> 
> > so i'm working my way through an implementation of the basic rock-ridge
> > extensions, re-working libisofs to read a file from disk and stat it's
> > attributes, when it hits me: is this sane?  so i thought some more about
> > it, and realized that directories will have an even larger problem than
> > files--people create "virtual" directories in their cds, so there isn't
> > always a physical directory to stat.  with this in mind, i think it
> > makes more sense for libisofs to let the application pass in the file
> > attributes, defaulting to 644 in case attributes aren't specified for a
> > file, and 755 in the case of a directory.  this also allows applications
> > to be designed so that the user can change file permissions/attributes
> > on the cd without effecting those on disk.
> >
> > the downside is that it will mean an api change.  is this acceptable?  i
> > was planning to make a global struct to hold this info, and add it to
> > the parameter list of iso_tree_add_dir and iso_tree_add_file.  i'm
> > modifying these two functions to generate the character buffers which
> > store the rr information relating to their particular file or
> > directory.  anyone see a problem with this approach?
> 
> That API is pretty much yours, and I certainly don't consider it to be
> frozen. :)
> 
> At the time of my last release, I don't think libisofs even worked, so
> I really doubt there are any users counting on it staying the same.
> 
> But if someone is, by all means, speak up :)

noone in the coaster camp is using any libisofs code as far as I know. I
think Derek is right in saying that there will probably not be any
complaints with api changes.

--
Sean Harshbarger