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?
Scenario
I have noticed that it is technically possible to request a
gzipto self:And then to
gunzipto self:But if we then slurp the resulting
foo.txtWe 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
copyandmove.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-treedoes 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?