I ran into a situation where my backups were overwriting each other and couldn't figure out why. The default filename by the module is [site_name], but I have a really long site name, so the appended date was getting cut off. The filename appears to only allow for 50 characters plus .sql or .sql.zip. Once I shortened the Site Name, my regular backups stopped overwriting each other.

There should be a warning about this or a sample filename preview when setting the filename.

CommentFileSizeAuthor
#4 682574-filename-limit-1.diff4.9 KBjeffschuler

Comments

jeffschuler’s picture

I've run into this issue a few times, myself.

A warning would be appropriate. And I like the idea of providing a preview...
The easiest solution might be to truncate the name before the date is appended...

Does the filename really need to be truncated to 50 characters, anyway?

ronan’s picture

I don't really remember. I was trying to stay below a 64 character file name limit (leaving room for file extensions) but I don't remember why 64. I'm not sure what system I was imagining would choke on filenames longer than that. I'll raise this limit when I get a chance.

vertikal.dk’s picture

I just ran into another problem related to the limited length.

In my case I had made a filename using tokens and set to [site-name]_[site-date-yyyy][site-date-mm][site-date-dd] giving me a file with a date stamp in the filename. The name itself will rarely be long (like mysite_20100630), but the tokenized name is longer than 50 characters and the module will not save my profile, but returns a database error.

If there's a problem with the length of filenames, it should be checked on the generated filename and not on the tokens. I had to change the filename field to Varchar(255) to accept my filename pattern.

Martin

jeffschuler’s picture

Version: 6.x-2.2 » 6.x-2.x-dev
Status: Active » Needs review
StatusFileSize
new4.9 KB

This patch:

  • Increases the db filename column's length to 128. This string is pre-tokenization and pre-appending of date and file extensions, so it's 128 to match Drupal's default text field length.
  • Fixes the description for that field in the schema, (as well as space-missing typo.)
  • Defines a filename max length at 255, (maybe there's a way to use a platform-defined constant?)
  • Adds a function, _backup_migrate_filename_append_prepare() to prepare a filename string for text to be appended to it, to ensure the concatenated string stays within max filename length.
  • Changes the name of _backup_migrate_clean_filename() to _backup_migrate_construct_filename(), (adding the timestamp is not "cleaning"...) and incorporates the preparation function.
  • Runs the preparation function before appending filename extensions to the filename.
    ...This one should maybe happen earlier on in the process, so we're not trimming the timestamp part of the name, (since the timestamp is ultimately what ensures we're generating unique filenames.)
  • I've tested this in a number of different ways, but it probably deserves a simpletest... Reviews appreciated!

ronan’s picture

Status: Needs review » Fixed

Commit applied and pushed to dev.

Thanks!

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.