After updating to 7.15beta6 I noticed that my automated backups were no longer working.
Upon closer inspection I noticed the issue is that /system/backup/save no longer accepts names with spaces, and will automatically convert them to _
doesn’t seem like it’s a file system limitation as i can still upload files with spaces to the device.
Unless there is some new limitation, I’d very much like to keep pre-7.15 behavior and allow us to use spaces for the backup file names, because if not that would break my automated backups throughout my whole network as I eventually update them…
It’s a deliberate change, well published in change logs. Did you read through relevant “new version announcement post” before installing a beta version?
i actually read every release notes (i follow through RSS) and didn’t see anything regarding backups.
reading it again i am assuming it’s this, but i always assumed console changes were for the console itself.
*) console - replace reserved characters to backup and certificate export file names with underscores;
again, this would break my backup automation throughout my whole network and would require me to manually go and fix it as i update devices… why are these now reserved specifically for backup and export while previously they werent? for example, why are they not reserved for file names?
Just wondering why use in filenames spaces, special characters like slashes, dots and others crucial for filesystem just for readibilty? Why not to use compact standarized easy to parse names compatibile with any type of filesystem used behind the scenes?
Sample: YYYYMMDDHHMM_DEVICENAME_OTHERSHORTINTHO.rsc with no country specific letters, just pure ANSI set.
I know that it’s rather a rethorical question and does not help in that particular situation but KISS rule is the rule of thumb across the IT territories for me.
Already a “problem” since I started working with computers (mind you, that’s 1980) and I always tried to follow that rule: NO spaces or special characters in filenames.
I even remember I, O or X were not allowed as filename character on a mainframe (that would cause confusion with 1, 0 or wildcard, keep in mind there was no lowercase at that time).
; Command separator
& Background execution
( ) Command grouping
| Pipe
* ? [ ] ~ Filename metacharacters
{ } String expansion characters. Usually don't require quoting.
> < & ! Redirection symbols
! ^ History substitution, quick substitution
" ' \ Using in quoting other characters
$ Variable substitution
newline space tab Word separators
" " Everything between " and " is taken literally, except
for the following characters that keep their
special meaning:
$ Variable substitution will occur
` Command substitution will occur
" This marks the end of the double quote
\ Escape next character
! The history character
newline The newline character
' ' Everything between ' and ' is taken literally except
for ! (history) and another ', and newline.
\ The character following a \ is taken literally. Use
within " " to escape ", $ and `. Often used to escape
itself, spaces, or newlines. Always needed to escape a
history character (usually !).
This is yet another piece of evidence and major reason one should try to avoid RoS scripting in production at all costs as Mikrotik might break compatibility without notice at any time.
Since this isn’t the first time (and probably not the last) that Mikrotik breaks script compatibility, I think it’s more than fair to include a clear warning about this on the help page regarding scripting. Besides, spaces in file names have no significant effect that would justify this change otherwise we’d have seen a lot of complaints about this already.
Bottom line - one might wonder if R&D practices any QA sign-off at all. Excuse my French, but this is completely bonkers!
common sense would dictate not to use special chars in filenames anyway, especially when one can download files to other systems not supporting specific characters in filenames
All major operating systems like Windows, macOS, Linux, z/OS, Android and iOS utilize UTF-8. What other OS might have the compatibility issue you are referring to?
It’s actually UTF-16, but the real issue is that it has far more special characters than any other OS, primarily owing to its ancestry, its path scheme being a mongrel mashup of CP/M, Unix, and LAN Manager rules.
Most POSIX flavors have only two special characters: slash and null.
macOS adds colon to that, but not for the same reason as Windows; it’s a Classic MacOS holdover in HFS, inherited by HFS+, then APFS.
Windows defaults to UTF-16 as its internal representation but has strong support for working with UTF-8 in addition to the legacy CP-1252 and similar encodings. For example, Notepad uses either ANSI or UTF-8. The rest of the world defaults to UTF-8. However, none are limited to legacy US ASCII..
But that is still beside the point. Prohibiting spaces in file names breaks compatibility, as the OP found out. A suggestion would be to either make an exception for spaces or adjust internal file management to also replace ‘special characters’ with underscores to avoid breaking script compatibility.
what system are you talking about exactly where space is a reserved character? every system has supported space in filenames for as long as i’ve known.
comma would be nice too.
Sir mrz, for who that is not an expert like you, but learned using MikroTik devices from time to time (sorry not all your users are PRO), could you please spend few minutes writing a clear statement like “attention this version will break scripts if you are using special chars (like space, etc…), you can fix using…”
This can help dump users like me and professional that maybe made a mistake and didn’t had the time going through all the changes.
Thanks
Spaces - generally speaking - are a PITA, as well as a number of special characters that - while allowed on the file system may be interpreted by this (or that) program/language as an “own” special character and would need to be escaped.
windows, every linux, every bsd, mac, all of these have supported spaces in filenames for a very very long time without any issues.
what is this breaking exactly? why is this an issue exactly?
regarding programming, you are correct that you need a safety check in the path, but you need it regardless for sanity, and it needs to go somewhere.
you are simply moving the safe checking from underneath, completely transparent to end user, to the surface, breaking end user formatting for no reason.
again, if someone has a reason, i would like to see it!
not asking for random characters, just asking for space and maybe comma.
)