Skip to content

Consider gzip/gunzip to self #225

@lread

Description

@lread

Scenario

I have noticed that it is technically possible to request a gzip to self:

(require '[babashka.fs :as fs])

(spit "foo.txt" "foo")
(fs/gzip "foo.txt" {:out-file "foo.txt"})
;; => "./foo.txt"

And then to gunzip to self:

(fs/gunzip "foo.txt")
;; => Execution error (FileAlreadyExistsException) at sun.nio.fs.UnixException/translateToIOException (UnixException.java:94).
;;    ./foo.txt
(fs/gunzip "foo.txt" "." {:replace-existing true})
;; => 10

But if we then slurp the resulting foo.txt

(slurp "foo.txt")
;; => "��\b\0\0\0\0\0\0�"

We see that it is not the gunzipped file.

Option 0 - Do nothing

Users should know not to do that.

Option 1 - Doc

Add a little note to docstrings that gzip/gunzip to self is not supported

Option 2 - Throw

Throw when attempting to zip/unzip to self

Option 3 - Support Use Case

Actually allow for gzip/gunzip to self.

What do other fns do?

I looked at copy and move.
They are no-ops when copying/moving to self.
But they are different from gzip gunzip which also does a transformation.
So, not applicable.

copy-tree does throw on an attempt to copy under itself.

Proposal

I think Option 3 - support use case - is too obscure to bother with.

My preference is Option 2 - throw.
Explicitly don't allow it.
Help users discover they made a mistake.

But I think Option 1 - doc - is also worth considering.

Whatcha think?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions