So Where’s My File?
May 15th, 2013Ever 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?
Print This Post
Of course people care about file systems, at least those people who are paying attention. We want to know where our files are, what they are, and how we can get at them. It’s about access and use: something that gets in-between me and my ability to do what I want with a file is a bad thing; this is especially so when the file system puts up impediments. This is why I won’t be switching to iOS for my main work machine anytime soon, even though an iPad + keyboard would do 90% of what I need: I want control over my files, how they are stored, and what I can do with them. iOS currently handcuffs the user in that respect; if that happens in OS X (and I don’t think it will; someone has to write iOS apps, and developers will give over file control when the sun burns out), I’ll be moving over to Linux, even with all the headaches such a move would entail. I don’t mind Apple dumbing down the general user’s experience of the OS so long as they don’t take away capabilities, restrict interoperability, or force us into sandboxes.
@Walker, They shouldn’t have to worry about where a file is. It should, under most circumstances, just be available.
When you have to go looking for your stuff, there’s a problem. This might be something Apple needs to think about a little more than they have so far.
Peace,
Gene
While I agree that users shouldn’t have to worry about where the hardware has put a file, having it magically available to the apps that can cope with it and the users with permission to see/edit it is not a simple thing to achieve. The current sandbox model is far more magical than the traditional hierarchical file system, but it completely prohibits sharing between apps or users. Duplication and version control become an even bigger problem than locating a file in a traditional system.
Documents emailed from person to person are easily lost track of and cause massive unnecessary duplication. Searching by date is no guarantee of finding the latest version. Collaboration tools that store documents in communication threads are only slightly better. Even where central repositories are available the simplest feature can wreak havoc. Some of our corporate Dropbox folders contain 10 conflicted copies of the same document. It is my speculation that this happens with headers and footers that contain the current date. Every time someone opens the document a header or footer changes and thus a new version of the document is created. Whatever the cause it’s wasting huge amounts of storage and bandwidth as the folders sync with hundreds of users scattered across the globe. It’s also making it hard to find the latest version of anything.
In trying to design a more modern user interaction model for computer files one is immediately struck by the fact that both document centric and app centric behaviour is considered normal. Searching for a file and double clicking it with the expectation that an appropriate set of tools will magically appear is document centric behaviour. On the flip side launching Mail and expecting all your messages to magically appear is app centric behaviour. Both are valid viewpoints
If we try to move all the way to a fully app centric future there will be huge challenges to overcome. Every app will need to be able to read and query a database style file system that presents the files that app can cope with and those the current user has access to. Each will need a UI for entering search terms and every file will have to contain meta data enabling it to be located. A user who forgets to include a single keyword could doom others to hours of fruitless searching.
Going fully document centric doesn’t make sense either and would never be supported by the software industry.
I think we’re going to see improved variations of the status quo for as long as people need to share information with others.
What’s wrong with double-clicking on files to open them? It’s the fastest way to get them open.
I don’t want document centric organization or app centric organization, I want me centric organization.
I create things on my computer. And then next day I create more things. And each of these things is massaged by several different programs. And eventually I pack them up and give them to someone else who pays me for them. And then I put them away in another place so that I’ll have a copy.
iCloud is completely useless to me. In iCloud I am not the master of my own domain. On the other hand, dropbox is useful, because I can organize it the way I want to.
I understand that grandma chronically loses her files, I support users like that. But I am not grandma, and I don’t want a filesystem designed for her. The best thing to do for grandma would be strongly typed default locations. It’s a Word/Textedit/RTF file? Put it in the Text location. It’s a Graphics file? That goes in the Graphics Destination. And so on.
Every now and then there’s talk about ditching the traditional file/folder format. I fervently hope this never comes to pass. Reason: I manage a website, so I’m keenly aware that the traditional format is permanently enshrined in the structure of URL address, and of the chaos that would be created if we walked away from this structure. A URL address instructs your browser to go to such-and-such a website, then look inside a specific folder (or, in many cases, to drill down into a nested set of subfolders) to find and display the specified file. Take this away and the entire system would break down. To post new pages, a new URL system would need to be invented and presumably all the billions of pages already posted would become inaccessible. Leave the f/f structure on servers only? Not possible. Those of us who manage sites need to have a f/f structure on our local computers that exactly mirrors the structure remotely posted on our servers (actually, it’s the other way around, the remote structure has to mirror the local one). I don’t think those people plumping for an alternative to the file/folder structure have the slightest clue of havoc this would wreak.