Filename Renaming For Different OSes Before Moving or Importing: A Tool Wish List
» Email someone you know about this article.
Filenames have to be compatible with the operating system and, often, with more than one OS. Different OSes have different requirements, so it’s common for a filename to be rejected by a given OS. This includes directory names. If your OS names other things, they might be included, too. If you’re bringing an already-named file in and the name is refused by the OS, the OS either renames the file, which is somewhat unpredictable and can make finding it later harder, or tells you you’ll have to rename it yourself, which is slow and inconvenient, especially if you have lots of files you have to rename one by one. So, before you move a bunch of files between platforms, you might prefer to have compatible names already. You can be more efficient and more thoughtful about names in the first place. Even if one OS version had a little-known variation in its filenaming requirements that causes an error in your renaming, that can be rare enough to still save you time overall. You might like a tool that can handle that for you. It would raise the efficiency, leaving the thoughtfulness to you. I don’t have such a tool and I don’t know of one. Hopefully, someone will create it. It could have two components: a full-featured app you can invoke when needed and an always-on program that sits in the background looking for new file-naming operations underway. If one program can serve both purposes, that’s fine. The app could look wherever you’d like, at one file, in one directory, at several that aren’t even adjacent, at everything, or anything in between. You would choose, in settings, the OSes for which you want compatibility, which almost certainly would not be all of them. The filename criteria include what’s permissible or not, such as length, character selection, and case (including case-sensitivity and case-awareness), what has special meanings or not, such as , and interaction with non-filename characteristics, such as path length, affected by directory name lengths. The always-on program would reside in memory whenever you have the computer on. If you could possibly name a file, the always-on program would watch for it. If it sees naming, it would invoke the app, which would test the name while naming is going on and alert you if it would be incompatible if moved. (Always-on programs have different categorical names under various OSes. They’re called daemons in Linux and Unix, TSRs in DOS, and so on. it seems that today an always-on program could simply be an app running in the background and still able to detect events, thus, for some OSes, no longer a separate category of software.) Maybe you’d like to have your own conventions for some of your files and a way of checking compliance. Each custom settings set could be named for later reference, could have a revision history, and could be copyable to other instances of the app. You could create a convention within an existing system. Maybe, within DOS, instead of 8.3, you wish for 7.2. I’ve used 8.3 and 7.2 sounds masochistic, but it could be arranged. You would simply define a subset of possibilities within a known namespace. When one system is more restrictive than another, the reverse might also be true, based on different characteristics. You might want to make a name compatible with both systems, so you’ll want to know whether a name is compatible with both, or with more than two systems. You might want to define and preserve a ruleset as being that which is compatible with multiple systems you’ve selected. If a ruleset depends on other rulesets and an independent ruleset changes, you’d want the dependent ruleset to automatically update its rules, probably with notice, optionally including details. Or, you might want to generate new rulesets, so you could keep the old ones, such as if you keep old OSes in production use. It is possible, at least in theory if not in practical terms, for no name to be acceptable to two rulesets. You’d want to be told this. It’s also possible that very few names would be acceptable to two rulesets. That situation might be hard to discern except through experience, so you’d want to attach, within the app, a note to both rulesets about that practical limitation. Uniqueness of a path including a filename is probably required by most OSes. If the app wants a renaming and the default renaming or the user’s renaming results in a failure due to nonuniqueness, the user should be able to rename either the filename or another component of the path in order to achieve OS compatibility. Permissions have to be compatible. If a user needs permission, renaming has to be compatible with the necessary permissions. If meanings would change due to renaming, such as if a file would become hidden or would no longer be recognized as a backup, notice should go to the user doing the renaming. When a new name is desirable but not possible on the present OS, and in some other cases, it might be useful to store a file with date-time-stamped information about issues involving renaming, such as an intended name that couldn't be applied where the file was at the moment, and that accepts comments from users. Batch processing could be supported by the app, saving a lot of time, and complex renaming rules could be applied to a batch and remembered for later batches. I conceptualized this some years before writing this, but I didn’t try more developmental work. This is a wish-list item.
