Ever since the very first Mac appeared, the question “Where’s my file?” has been asked over and over again. Depending on the app, it may be saved to one folder or another by default, and there may be special settings for that. But at the end of the day, the location might not be crystal clear.
Worse, it’s not that the normal OS X tools to locate a file offer the best solutions. Many Mac users don’t even use the Open/Save dialogs, let alone a third-party enhancement, such as Default Folder X. Indeed, I’ve observed people double-clicking directly on files to open them, even when the proper app is already running.
The heart of all this is that we have come to regard a file as a single chunk of data that exists in a fixed spot on your Mac or PC’s hard drive. You change it, the original file is altered. If you erase that file, it’s gone. Well, not actually. The normal Erase or Delete function will remove the pointer or index entry to that file, making the space on your hard drive available for new data to be written.
Now as has been pointed out elsewhere, Apple has been working towards removing the direct reference to a specific file in a physical location. These days, the stuff you create on your Mac may be stored on a local hard drive, an iPhone, an iPad, or even in iCloud. When it comes to the cloud, you’re not dealing with a single computer with a single drive, but a sprawling network of servers, which means there may not be a specific place where that file is located, and it’s possible locations may shift from time to time as servers are upgraded or content is moved to a different datacenter.
The lack of an apparent visible file location is particularly apparent in the iOS. With applications sandboxed, each app owns its own document space. If a document is opened in another app, it has to be shared with that app, which will then create its own copy. Confusing? You betcha! Multiple versions may also mean that each is in a separate state of completion, and may not represent the file’s current state or revision level.
As OS X takes on more of the characteristics of iOS, some wonder whether the way files are managed, not to mention the actual file system, will change too. I suppose it’s possible, but Mac users are still wedded to the file/folder routine, although iTunes and iPhone, for example, shield you from such fineries.
The key problem with iOS files is the lack of a central repository. You’d certainly want to use space efficiently, particularly on an iPhone and an iPad, which would seem to argue against having a separate copy for each app. However, opening up file privileges of this sort seems to argue against Apple’s sandboxing scheme. While I understand the reasons for wanting to keep the platform as free of malware as possible, when the customer is inconvenienced, something is wrong.
There are also reports that Apple is working on revising the aging OS X Finder, but you wonder whether it’ll make file navigation much simpler, or just add a few refinements, such as tabs. Does that really address the ongoing confusion over file locations and access. In the end, do we even need the current file/folder scheme, which is so 1980s? And, yes, I know Spotlight can help, or confuse you even more with loads of choices that may still omit the file you’re looking for.
This is but one dilemma that Apple will no doubt have to confront as OS X and iOS are updated in the years to come. I suppose there might even be some changes with the next update, but that won’t be known until the WWDC in June.
The other issue, one I’ve raised already, is whether it’s possible to have a single file format for all documents. But that isn’t just choosing the right format, and one of our readers suggested HTML as a possibility. It’s the problem of including all the file information that would allow you to open any document created in any application. That move would also require the support of app developers who make their proprietary formats a matter of reducing access by competitors. That hasn’t stopped other app developers from finding “unofficial” ways to parse data, but it also means that the translation process is often highly imperfect.
I wouldn’t presume to guess whether it’s possible to persuade some of the worst offenders when it comes to proprietary file formats, such as Adobe, to put them all into the public domain. But I think that the file format shouldn’t be the selling factor for an app. It should be about performance, having the features you want, along with a reasonably user friendly interface. Whether another app can read your documents is probably one of the last items on the bill of particulars, although it’s quite important if you want to read existing documents after moving to a new app. This is particularly true if you’re switching, say, from a PC to a Mac, and there’s no equivalent app at hand.
For now, I’m avoiding the question of whether Apple will continue to use its aging file system, or come up with something modern and more robust. Besides, regular people don’t care about file systems anyway, right?