Hello,
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 “-”.
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.
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
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.
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 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?
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.
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.
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: Slashes in file names - Apple Community
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