4 ms·
The current copying paradigm is utter 70's. Here's a hint for you from the 2000's, you Microsoft or Linux or Gnome developers: What I would like is that copies
by yason 15y ago
The current copying paradigm is utter 70's. Here's a hint for you from the 2000's, you Microsoft or Linux or Gnome developers:
What I would like is that copies seem instant and transparent. Actually, I wouldn't like to think of copying at all. I "copy" (or merely just order) a file to (appear in) some place and it immediately becomes accessible from there. Or I decide to move it back a few seconds later and I can do that.
In reality the computer should manage the low-level copying internally and consider it more like syncing.
I shouldn't have to care about how long something takes or how the kernel will queue the actual copy operations, or whether it copies anything at all but just creates a copy-on-write mapping to the same data. I also shouldn't have to wait for copying: I should be able to just copy something and immediately turn off the computer. The operating system would continue copying the blocks, if necessary, when it's restarted later. All copy operations ought to be logically atomic as well: either a copy is immediately made or it isn't, the physical details of copying and remapping the corresponding blocks shouldn't be any of my concern.
So, an immediate, transaction-based and logically coherent file operations with automatic kernel-level delayed-I/O backend is what I would call the 2000's.
I hope that there already is at least one research O/S somewhere that would do this.
- Mavrik 15y agoSo basically, you'd "copy" a file on an external harddrive, plug it out and then have a surprise when you'd notice that the file isn't actually there when you get to another computer? Because cross-device copying is the only place where this operation is slow, with modern HDDs all other operations are instantanious for all intents and purposes. Good idea but you really should have put more tought on it.
- thisisfmu 15y agoWhy let the exception case (removing an external drive quickly) ruin the main use case? going forward it seems reasonable to assume ubiquitous network connectivity, so you can simply treat external drives as a cache and show a non-modal alert "please reconnect for sync, expected to finish within X minutes" iff the amount of data synced is large enough to matter via a 3G connection.
- yason 15y agoDescribing an end-user experience doesn't need to account for all the details in the first sketch. But pending sync is one of the easiest ones to handle. You obviously unmount or decouple your external drive in software first and that's a good place for the operating system to inform you that: Ongoing I/O for your USB mass storage device. Wait for completion before unplugging. And if there are many parallel I/O streams going on and this dialog is invoked, automatically prioritize anything that's being copied to the external hard drive first so that the user can unplug it as soon as possible.
- sid0 15y agoYou obviously unmount or decouple your external drive in software first You do? I'm often too lazy to.
- sp332 15y agoI used to just pull it, but a half-dozen missing and corrupted files (one of which was a final project for a class in college) trained me out of that habit.
- AndrewDucker 15y agoYou obviously unmount or decouple your external drive in software first You haven't met most users, have you?
- ams6110 15y agoPrecisely. How many users do you know who "safely remove" thumb drives, and how many just pull them out of the USB slot?
- encoderer 15y agoBut there's a whole class of problems here, not just removing an external drive. I'm at my friends house, copying files from a network share over his wifi. I'm copying from mounted network shares at home over the internet. I'm putting files on, or pulling them off, a USB stick. If copy turned into the feature you described, there would have to be a 2nd "no, REALLY, copy" command. Hardly a step forward. That being said, there's no reason it couldn't work the way you describe if the system knows it's copying to/from local physical discs.
- chetan51 15y agoWhy stop there? Why not just stop worrying about files and folders, and just think about documents, pictures and videos instead? Why should I have to care about the low-level filesystem at all? Cue iOS.
- sid0 15y agoBecause that paradigm is currently restricted to rich people in first-world countries where always-on fast internet is ubiquitous and you can sync everything to the cloud without much trouble. The rest of us will continue using not-very-high-capacity USB sticks to move photos, videos and other data around for the foreseeable future.
- trezor 15y agoCue iOS. Which was a nice experiment which proved that it didn't work. You know what you can't do on iOS which most users want to be able to do? Yeah. Work with the same document from multiple viewpoints, or applications. You can't work with documents across applications on iOS because you supposedly don't have files. Like I said: A nice experiment, but it proves that "no files" only works for the simplest of use-cases and limits the ability to work with data beyond the limits that people reasonably expect to find.
- ugh 15y agoNah. iOS didn’t have the time to prove anything at all. It’s not done yet.
- wakeup 15y agoI dont know if you have noticed, but iOS is the worst operating system since DOS.
- jmilloy 15y agoThis sounds like a shortcut. Those exist. Also, besides copying files to removable drives, etc, the primary reason I copy a file is because I want two separate copies. Otherwise I would move it.