File name characters changed upon export

I’m running into an issue where file names are changed when exporting from DT into Finder. The characters “/” and “*” (perhaps others, not sure) are being changed to “-”.

Here is a list of file names in DT:

And here is how those names are changed upon exporting to Finder:

(I just dragged-and-dropped the files into finder.)

Is there any way to preserve the original characters during such an export?


See here for a previous discussion on this topic. My understanding is that your only workaround would be to change the characters to “non-illegal” ones prior to export.

1 Like

Thanks for the link!

As in, get rid of the characters that DT will change upon export so that DT doesn’t change anything upon export? That wouldn’t work for me, as I’m trying to preserve the “/” and “*” so as to remain consistent with the source names prior to introducing the files into DT to begin with (the names aren’t my fault–they’re just simple paper folder names preserved in the electronic names for consistency).

Or, are you suggesting that there’s a way of configuring what DT deems “illegal”? (It seemed like the users commenting on the end of the thread you linked would like the ability to configure for greater usability, being less concerned about the possibility that an “*” or whatever would trigger some catastrophic domino effect in some far-away land of computer code. I mean, for me anyways, it’s just a file name—come on DT lighten up and let us use a “/” haha.)

Moreover, while I’m ignorant of the many considerations, it seems like the DT reasons concerning compatibility are not relevant because this happens on EXPORT from DT to Finder, not on import. One could understand if DT can only work right in the absence of illegal characters and for that reason changes them to non-illegal ones upon import. But it seems weird that it would preserve them in DT (where they supposedly cause problems) only to change them upon export to Finder (which has no problem with them).

A / in a filename is simply not possible on Unix-based systems. MacOS is one of those. The / is the path separator, much like \ is in MSDOS/Windows.
This is out of the control of DT.
Historically, Macs used : for the same purpose, so that’s a special case, too.
The other characters mentioned by @BLUEFROG in the other thread merely cause inconveniences in shell programming, I think.

1 Like

No, unfortunately not. I’m suggesting changing / to | and * to † for example. A PITA maybe, but if you determine what is changed to what, the change is transparent - meaning, e.g. that if you are later searching for a file it would be more obvious to you what to search for. Changes of that kind can easily be batch processed with a script. So I’m kinda suggesting you make the best of it :slight_smile:

When I read your post again, I noticed that you’re obviously falling into a representational trap of the Finder here. Whereas you can apparently name a file “foo/bar” there, it is in fact named “foo:bar” in the filesystem (as revealed by ls in the terminal). If I were in the mood, I’d try to figure out what happens when you copy this file to a USB drive with an (Ex)FAT filesystem on it …
On the other hand, try creating a file named “foo:bar” in the Finder … Obviously, MacOS does something “intelligent” here by feigning to support “/”, while in fact it silently converts it to colon in the background.
So it is apparently quite reasonable to prevent certain characters in file names. At least those that are special to the prevalent file systems, namely “/”, “:” and “\”. As to space, “*”, dots et al … I think the times of being careful about those are long gone. Especially since there’s also no requirement to limit filenames to 8 characters plus 3 for the (mandatory) extension.
Just to illustrate the interesting consequences: I created a file with / in its filename and send it attached to an e-mail to myself. Cf the screenshot: colon in the overview on the left, slash on the right.

A look in the mail’s source reveals this:

Content-Disposition: attachment;
Content-Type: application/octet-stream;

You can of course insist that your filenames have to contain slashes. And you can of course believe that they do. However, the stark reality is that this is just a Finder figment. There are no slashes in filenames on Mac OS. Everything else is an alternative fact.


thanks for that workup @chrillek :+1:

1 Like

Thanks for the engagement! Is there no way to get Finder to believe in the figment after DT passes the files off during an export?

When initially moving them from Finder to DT, DT believes the Finder figment: the file names appear in DT after that move as they had in Finder. So it seems like DT knows something about the appearances that conceal the reality of the “:”. But somewhere between DT and moving them back to Finder, this drops away—and we’re left with the bitter reality of the “-“, which is just not what the paper files had written on them; they said “/“.

No way? Just retype it all out to return to the world of figments?

Nope. I suggest you google for “MacOS slash colon”. There’s abundant information on this topic already.

It makes you believe in it :wink: Have a look in DT’s log window:

Computers tend to have different requirements than paper (and vice versa). Try as you might, a slash in a file name will eventually go away. As I said: try saving them to an USB stick and see what happens. I bet you’ll see either a colon in the filename or an error message on your screen.

Sorry, but this argument is going nowhere. It’s as if you had asked for support of ñ twenty years ago in an ASCII file – it simply wasn’t there. There are limitations one has to cope with.

@Blanc’s suggestions are sound: Whenever necessary, you can revert this representation to the original one – i.e., when this is really needed.

1 Like

And you really can probably completely automate both steps - DT could change the name of any document containing / or * on import; actually, you could probably script Finder to change the name of any file containing | or † back to / and * (in the visual representation, anyway). Whether that is really necessary, or whether you can live with the visible file names not being identical to what you have come to expect is for you to decide. :slight_smile:

1 Like

Oh yeah, hmm, interesting. This guy (answer) seems to think the / is only a problem for Unix and not for Finder (Mac software) per se:

Anyways, I’m not in a position to learn technical matters or put a horse in one of these races–I’m just trying to use DT and move precise names back and forth from Finder (understanding DT etc. is beyond my level). Since that’s my goal, it seems that perhaps I should give it an hour or something to look into

Anyways, thanks for your engagement!

Interesting idea! I will give it a stab!

Thanks for the ideas!