[bug #61050] Early abort should not write 0 Byte output file

[anonymous]

URL:
  <https://savannah.gnu.org/bugs/?61050>

                 Summary: Early abort should not write 0 Byte output file
                 Project: GNU Wget
            Submitted by: None
            Submitted on: Tue 17 Aug 2021 02:20:37 PM UTC
                Category: Program Logic
                Severity: 3 - Normal
                Priority: 5 - Normal
                  Status: None
                 Privacy: Public
             Assigned to: None
         Originator Name: Matthias Hörmann
        Originator Email: matthias.hoermann@saltation.com
             Open/Closed: Open
                 Release: trunk
         Discussion Lock: Any
        Operating System: GNU/Linux
         Reproducibility: Every Time
           Fixed Release: None
         Planned Release: None
              Regression: None
           Work Required: None
          Patch Included: No

    _______________________________________________________

Details:

Using Debian wget 1.21 or Gentoo 1.21.1 the following behaviour can be
reproduced:

Calling

/usr/bin/wget -O 'GeoLiteCity.dat.gz'
'http://geolite.maxmind.com/download/geoip/database/GeoLiteCity.dat.gz'

the download fails because the domain no longer exists with

--2021-08-17 16:11:53-- 
http://geolite.maxmind.com/download/geoip/database/GeoLiteCity.dat.gz
Resolving geolite.maxmind.com (geolite.maxmind.com)... failed: Name or service
not known.
wget: unable to resolve host address ‘geolite.maxmind.com’

and an exit code of 4.

It also creates the output file as a zero byte file.

Clearly a download had not even started here so there is no reason to create
the file already (and especially to not clean it up on failure if it needs to
be created early for technical reasons).

This became an issue when our Puppet manifests then proceeded to skip the
download of the file that was there and tried to unpack the 0 byte file in the
next Puppet run (it correctly displayed the failed download command as failed
in the original run).

It just makes it harder to determine whether the download already happened for
a significant portion of failure cases and I also do not see a situation where
it would be useful to have an empty file that has literally nothing to do with
the file on the server (no metadata, content,...).

I understand that detecting a download by existence of the file can also be a
problem on partial downloads but for reasonably small files that happens much
more rarely than all the various errors that can occur before a download even
starts.




    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?61050>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/