extract icon indicating copy to clipboard operation
extract copied to clipboard

The FS interface doesn't have to force using io.File

Open simeonmiteff opened this issue 1 year ago • 0 comments

Similar to #25 - I have a requirement to do something other than vanilla I/O against an io.File, so changed the OpenFile() signature like this:

diff --git a/extract.go b/extract.go
index 9ab7ef9..0c02a07 100644
--- a/extract.go
+++ b/extract.go
@@ -103,7 +103,7 @@ func (f fs) Symlink(oldname, newname string) error {
        return os.Symlink(oldname, newname)
 }
 
-func (f fs) OpenFile(name string, flag int, perm os.FileMode) (*os.File, error) {
+func (f fs) OpenFile(name string, flag int, perm os.FileMode) (io.WriteCloser, error) {
        return os.OpenFile(name, flag, perm)
 }
 
diff --git a/extractor.go b/extractor.go
index c9f28c6..0140d54 100644
--- a/extractor.go
+++ b/extractor.go
@@ -31,7 +31,7 @@ type Extractor struct {
                MkdirAll(path string, perm os.FileMode) error
 
                // OpenFile opens the named file with specified flag (O_RDONLY etc.).
-               OpenFile(name string, flag int, perm os.FileMode) (*os.File, error)
+               OpenFile(name string, flag int, perm os.FileMode) (io.WriteCloser, error)
 
                // Symlink creates newname as a symbolic link to oldname.
                Symlink(oldname, newname string) error

...it turns out this is fine since os.File implements io.WriteCloser and none of the implementations of the interface need anything more, but relaxing this constraints let's me do something more abstract with the FS interface in my application.

I realise this is an API-breaking change, but would you be open to an PR for that (perhaps v5.0.0)?

simeonmiteff avatar Oct 18 '24 07:10 simeonmiteff