[Import/Export][Bug] Exporting alerts with faulty names

[phospi]

Hi there,

I'm using cfme-rhconsulting-scripts to export cfme alerts. I observed that for every manageiq alert there is a file created where the filename == alertname. In manageiq it is perfectly fine to use every available unicode or special character to name the alert. However, when exporting such an alert name as a filename things become awkward. I know that UNIX-based filesystems are less bitchy about special characters. AFAIK, it is a best practice to avoid special characters in filenames. I guess that a lot of problems can arise from just copying any character in a filename without escaping special characters.

Issue 1:
I just tested that I can create alerts with 300 characters. As you might know, the maximum length for a file name is about 250 characters. Such alerts currently raise an OS error as you can see here:
Errno::ENAMETOOLONG: File name too long @ rb_sysopen - /MIQEXPORT/alerts/abcdoflkgndaslgndflskgnlgnregklmgknrkmgrkdfadflnafaidnsflasfjoewrjpaewmffklmöasfokaewrkdklgmvdvdmksflanofeawfmwpmfsolamfdsklfnkglw4eirnflaeiwnflawnfkawöolmfoö3ewmfkoaewöfmewolgnfklgneiwkgneiwrnfewnfewlianflasnflknaewflnaweflvnlwaenvlaewnflaewnglaewnflaewn.yaml

Issue 2:
We just had the issue that we exported an alert with the following special characters: ":<>%". When exporting this into git there was no issue but importing it again into a windows machine broke the git repository because the file name was truncated after ":".

I can't tell exactly where address this issue? I see two options.

First, we can change the way export functions work. I suggest exporting elements by id or guid. Does someone see a problem by doing so?

Second, manageiq could disallow the use of special characters in any name field inside of manageiq. Would this make sense or will this strongly impact the user experience?

Any suggestions on this issue?

Kind Regards,
phospi

[phospi]

Additional issue with the same cause:

rake aborted!
Errno::ENOENT: No such file or directory @ rb_sysopen - /tmp/miqexport/service_dialogs/My_not_so_nicely$%&amp;"%$&amp;%&/_named_dialog.yml
/var/www/miq/vmdb/lib/tasks/rhconsulting_dialogs.rake:10:in write' /var/www/miq/vmdb/lib/tasks/rhconsulting_dialogs.rake:10:in block in export'
/var/www/miq/vmdb/lib/tasks/rhconsulting_dialogs.rake:7:in each' /var/www/miq/vmdb/lib/tasks/rhconsulting_dialogs.rake:7:in export'
/var/www/miq/vmdb/lib/tasks/rhconsulting_dialogs.rake:160:in `block (3 levels) in <top (required)>'
Tasks: TOP => rhconsulting:service_dialogs:export
(See full trace by running task with --trace)

[miq-bot]

This issue has been automatically marked as stale because it has not been updated for at least 3 months.

If you can still reproduce this issue on the current release or on master, please reply with all of the information you have about it in order to keep the issue open.

Thank you for all your contributions! More information about the ManageIQ triage process can be found in the traige process documentation.

[chessbyte]

I don't understand the use case - why have a really long alert name? Maybe the code should limit the length on the alert name. Please re-open with more details.

[Fryguy]

Reopening as this issue covers all cases where automate objects are not exportable.

• names that are valid characters in automate are not valid characters in files names
• names are too long and break filesystem limits

See also #19702

[miq-bot]

This issue has been automatically marked as stale because it has not been updated for at least 3 months.

If you can still reproduce this issue on the current release or on master, please reply with all of the information you have about it in order to keep the issue open.

Thank you for all your contributions! More information about the ManageIQ triage process can be found in the triage process documentation.