MySQL Bugs: #37979: Backup file with compression works without .gz extension

Bug #37979	Backup file with compression works without .gz extension
Submitted:	9 Jul 2008 3:33	Modified:	10 Jul 2008 13:14
Reporter:	Hema Sridharan	Email Updates:
Status:	Not a Bug	Impact on me:	None
Category:	MySQL Server: Backup	Severity:	S3 (Non-critical)
Version:	mysql-6.0-backup	OS:	Linux
Assigned to:	Sveta Smirnova	CPU Architecture:	Any

Description:
As per the syntax of compression,
BACKUP DATABASE test to '1.bak.gz'
  WITH COMPRESSION;
or 
BACKUP DATABASE test TO '1.bak.gz'
  WITH COMPRESSION
  COMPRESSION_ALGORITHM = gzip;

Backup file with compression succeeds even if the file name is specified without .gz extension. Ideally this should not be the case, as in the location where backup file is stored doesn't properly indicate the compression. 

This is ambiguous to the users as they don't have clear idea on whether the file is compressed or not. (An example is shown in how to repeat section)

How to repeat:
mysql> backup database * to '/export/home/tmp/backup_dmp/compression/db12_compr_ar' with compression;
+-----------+
| backup_id |
+-----------+
| 27        |
+-----------+
1 row in set (13.51 sec)

mysql> backup database * to 
'/export/home/tmp/backup_dmp/compression/db12_compr_ar.bak.gz' with compression;
+-----------+
| backup_id |
+-----------+
| 28        |
+-----------+
1 row in set (12.45 sec)

Backup file location: /export/home/tmp/backup_dmp/compression/

-rw-rw---- 1 hs221732 wheel 131K Jul  9 02:00 db12_compr_ar
-rw-rw---- 1 hs221732 wheel 131K Jul  9 02:01 db12_compr_ar.bak.gz

From the above it shows that command works fine and database is compressed. and size of .gz and without gz both are the same.

Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://dev.mysql.com/doc/ and the instructions on
how to report a bug at http://bugs.mysql.com/how-to-report.php

Quoting man gzip here:

  -S .suf --suffix .suf
              Use suffix .suf instead of .gz. Any suffix  can  be  given,  but
              suffixes other than .z and .gz should be avoided to avoid confu-
              sion when files are transferred to other systems.  A null suffix
              forces  gunzip  to  try decompression on all given files regard-
              less of suffix, as in:

                  gunzip -S "" *       (*.* for MSDOS)

              Previous versions of gzip used the .z suffix. This  was  changed
              to avoid a conflict with pack(1).

So I don't see any problem with avoiding suffix or with specifying alternate one.

Thank you for the feedback.

Yes, checking if file compressed looking into extension can be easier than examining output of `gzip -l ./*`. But why don't allow user to specify own extension? For example for security reasons?

Adding experience from my previous job,
where I was responsible for the integration of database backup 
with external archiver tools (ADSM, NetVault, NetWorker, ...):

Any restriction on backup names is risky, and very likely to soon fail, causing more harm than good.

Reasons:
1) What if you backup directly to a device, say a tape drive ?
   You cannot rename "/dev/rmt0" depending on whether your backup is compressed or not.
2) What if you backup through a named pipe, for further processing ?
   This was how we connected the database output to the external tool.
3) What if your backup name is restricted by other conventions of your environment ?

No admin can rely on a gzipped file being called ".gz", so the database should not raise such an assumption.
It is the admin's responsibility to come up with good names -
and if he prefers ".dbsavcomp" for "database save, compressed", so be it.