SoylentNews is people
SoylentNews
Our office recently updated to a new version of the Office Suite, and it still has an icon in the upper-left corner to perform the 'Save' function. Floppy drives have not been in use for years, and many children would not recognize a 3.5 inch floppy disk on sight. Programs have used this icon for years, because we have yet to find a suitable replacement. The CD/DVD can no longer represent saving, because they have come and gone. Even moving to the more abstract Piggy Bank icon would not work, because they are seldom used in the modern age. A USB Key icon may represent saving in some form, but the may not be around much longer if another medium gains favor. Does this mean that the venerable 3.5 inch Floppy will represent saving information to future generations, or should it be replaced by a different symbol?
(Score: 4, Interesting) by pTamok on Tuesday December 20 2016, @09:32AM
Coming from a VAX/VMS background, I have never understood why overwriting an existing file should be regarded as saving information. Most implementations of 'Save' I have encountered overwrite an existing file. The approach taken by the RMS filesystem on VMS was to write a new copy of the information in a new file, and increment the file version number by one. You had to explicitly purge older versions to get rid of them (there were, of course, automatic mechanisms to do this if you chose). MS-DOS did not have automatic file versioning, and the rest is history (until recently, where NTFS can implement versioning).
The current 'save' action should really be labelled as 'overwrite', and 'save as' actually be 'save'. 'Save as...' could also usefully prompt with a filename that had an autoincrementing version number (or equivalent).
Taking a large document, making some changes, then saving, usually means that the revision before the changes is lost. Some developers have included functions like change journalling and hidden backup versions, and some filesystems do simillar 'hidden' backups or implement checkpoints, but it is all pretty piecemeal.
The lack of good, stable file versioning in Linux has led me to look seriously at using NILFS ( https://en.wikipedia.org/wiki/NILFS [wikipedia.org] ) as a filesystem. It is not exactly mainstream, but it has some very interesting attributes.
NILFS supports continuous snapshotting. In addition to versioning capability of the entire file system, users can even restore files mistakenly overwritten or destroyed just a few seconds ago.
(Score: 4, Interesting) by FatPhil on Tuesday December 20 2016, @09:55AM
And before you accuse me of speaking from a position of ignorance, I have used VMS, and the fact that it was unable to distinguish (because it didn't even try) between an old version that was worth archiving, and an old version that should be binned, convinced me once and for all that it was an anti-feature, more than a feature.
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 2) by theluggage on Tuesday December 20 2016, @10:22AM
I have used VMS, and the fact that it was unable to distinguish (because it didn't even try) between an old version that was worth archiving, and an old version that should be binned, convinced me once and for all that it was an anti-feature, more than a feature.
For me it was using VAX C and discovering that the regular files created by the standard i/o library were incompatible with the "record-based" files created by every other VMS application... The VMS devs never did get the message that a file system wasn't meant to be a DBMS (probably the same folk who later tried to replace the Windows file system with a relational database).
(Score: 4, Insightful) by pTamok on Tuesday December 20 2016, @10:40AM
Well, I did use CMS* on VAX/VMS. Horses for courses.
I would continue to contend that the function implemented in most Office software is not 'Save', but 'Overwrite'. I take your point about being unable to distinguish between an old version worth archiving and an old version that should be binned, but I would suggest that perhaps you are looking for a function labelled 'Archive'?
Given the cheapness of disk storage, I would suggest, from a human interface point of view, that keeping a copy of all old versions is a viable, if not sensible insurance strategy, and if you are at all bothered by disk-space considerations, do a purge at a sensible time interval and with a sensible selectivity - which might possibly be set by the user, or a system administrator. You could explicitly set an automatic purge with keep=1 if you wished, and have the functionality you describe.
Currently, people operating office applications are able to completely trash their work by an inopportune 'Save' - this is not good. In a world where it is considered good practice to protect people from their mistakes, I would argue that creating a new copy each time 'Save' is invoked would be good practice, so rollback is possible (other methods of rollback could be used), and having both a 'Save As' function and an 'Archive' function would add belt and braces.
I haven't polled users to see if 'Save' operates in the fashion they desire, but the number of times I have had to restore old versions of critical documents for people who have saved changes that they didn't intend suggests something isn't working. NTFS does now allow you to restore previous versions of files, if you have that capability enabled, and know how to use it - however, many people operate on important documents held on USB sticks with FAT filesystems - including students writing theses.
The use cases: for a developer, who knows how to use a code management system; and and end-user, who probably doesn't know, and doesn't have access; are different. Developers are generally very computer literate, and are usually given access to the tools to do their job: end users often have to struggle with whatever they are given. Relabelling 'Save' as 'Overwrite' would help to prevent a number of occasions where people have shot themselves in the foot.
Thanks for your feedback. I agree, sometimes it was a chore finding which file version was the one that I wanted: but it was better than having to rewrite something because an accidental deletion had been made permanent.
*DEC's Code Management System.
(Score: 2) by DutchUncle on Tuesday December 20 2016, @07:32PM
Had to respond to "given the cheapness of disk storage". Back in the days we're all talking about, it wasn't. While being able to recover old versions of files is handy sometimes, it's not what you want most of the time. OTOH since in real life NO system actually overwrites the old copy - it really writes a new copy and then switches names, unless you work really hard at doing in-place operations (which only worked on certain hard drives) - keeping the old copy is not hard. OTOOH, leaving unlimited old copies around isn't such a good plan either. The solution might be simpler: we already tend to have a distinction between "save" and "save as"; if we just standardize as "save as" with an additional click to select "same name" (not just having it pre-filled-in) then it's as easy as it is now, and with the clarity you want.
(Score: 0) by Anonymous Coward on Wednesday December 21 2016, @12:45AM
The "write new data stream, drop old data and swap names" is not what seems to be done by many coders. How do I know? Any fucked program that tries to save, fails for whatever reason (disk quota, process crash, hw powerdown)... and now you have no valid data at all, new or old. The filesystem may not overwrite, but from user space the data is gone/damaged and will require some luck and special tools to recover.
So no, too many coders don't even know how to properly replace file contents, even if the method was in computing litetature at least since early 80s. Every 5-10 years all the data dance with fseek, fsync, etc will hit the news but coders will quickly forget again, or even go silly like hitting fsync over and over ("I heard this keeps the data, DO IT!") instead of plan correctly how to balance integrity and speed.
(Score: 3, Informative) by theluggage on Tuesday December 20 2016, @11:07AM
Coming from a VAX/VMS background, I have never understood why overwriting an existing file should be regarded as saving information.
OK, I've had a pop at VMS below, but, on reflection, maybe it was ahead of its time. With modern storage capacities, there's plenty of space for multiple versions or infinite undo histories... even with bulky files like video, images and audio you're mostly saving an "edit list" rather than multiple copies of the data. With a GUI you can display the "history" in a more useful way than VMS's "hello.txt;237".
Incidentally, Apple added file versioning to Mac OS years ago, and changed the Save/Save As.. protocol in their applications to "Save (this version)/Duplicate (create a fork)" with a time-machine-like scroll back through previous versions. Someday, MS Office and Adobe CS will support it and people may notice.
Then, one day, someone might come out with a version control system understandable by regular users - like "git" but, well, not like git [xkcd.com].
The "save" concept is already depreciated in many mobile apps, particularly on iDevices that hide their filesystem from the user. Instead, we have transparent auto-save plus an (emerging standard) "Share" button for distribution.
(Score: 2, Disagree) by Pino P on Tuesday December 20 2016, @06:17PM
Then, one day, someone might come out with a version control system understandable by regular users - like "git" but, well, not like git
If you can buy something on a web shop, you can use Git.
Add to cart: git add somefile.txt
Check out: git commit -m "warn about kernel bug 107651"
Shipping: git push
(Score: 2) by Pino P on Tuesday December 20 2016, @06:20PM
The "save" concept is already depreciated in many mobile apps, particularly on iDevices that hide their filesystem from the user.
I have lost data in Newton OS, the predecessor to iOS. NewtonWorks auto-saved without saving more than one level of undo. I accidentally selected all, deleted everything, and did something else that counted as a separate action, and my document was gone.
(Score: 1, Funny) by Anonymous Coward on Tuesday December 20 2016, @03:25PM
journaled filesystems motherfucker, do you speak it
(Score: 0) by Anonymous Coward on Tuesday December 20 2016, @05:00PM
I expect the future is "auto-save" with auto-versioning, similar to VAX/VMS, such that one doesn't have to press a button/icon to save. Saving is an ingrained habit for many of us, but if you think about it, we shouldn't have to explicitly keep asking for saves. Young people may even be able to forget there is a "Save" button in things like word-processors. You wouldn't need one except under rare circumstances. If you are using a memory stick (flash drive) and yank it out too quick, you may have a problem, but if storage copies are automatically done say every 7 seconds, then all you have to do is wait 7 seconds. Or close the document.
But unlike VAX/VMS's way of doing it, older versions may get gradually purged based based on frequency distance. In the background, minor changes or versions may gradually disappear (unless explicitly saved or overridden). The older something is, the less likely you need very specific sub-versions.
For example, 5-minute snapshots may get deleted after 1 day, then 15-minute snapshots deleted after 3 days, hourly snapshots after 1 week, etc. If the disk (storage) is getting full, you may be prompted (warned), and elect more aggressive version purging to continue, with the downside of less-frequent versioning snapshots.
I should point out that things like word-processors may have to change the way they store sections. Each paragraph my have to be treated like a record in a database instead of have one giant RAM image of the document. Otherwise, auto-save could be too disruptive because it's writing a fresh copy of the entire document on every version archive cycle.
In MS-Access there is no need for "save" for "direct" data entry because it uses chunk-based updating. This confuses data entry users at first, but they get used to it and like it. Word-processors and spreadsheets could use similar technology so the auto-versioning is only working on the record level. The risk of reference corruption (bad pointers) perhaps goes up, but full document copies would also be periodically made, similar to copying the .MDB (or .ACCDB) file in MS-Access say every 15 minutes. Thus, if the pointers get fubarred, you have a prior full-document version and lose no more than 15 minutes of work at the most. (Pointers should be checked for orphans or type mismatches by the system on full-doc save to catch any corruption early.)
(Score: 2, Interesting) by Anonymous Coward on Tuesday December 20 2016, @05:44PM
I started word processing on a Z-80 CP/M system, with an Emacs/Scribe offshoot called Mince/Scribble, later integrated as FinalWordII then sold to Borland and renamed Sprint. It opened a "swap file" on disk when it started and it was possible to set the time increment for fast incremental saves to the swap file. If something crashed, there was "FWRecover" which could unscramble the swap file (I believe pointers to short chunks of text) and restore the session including multiple editing buffers. Even on old, unreliable hardware, I don't think I ever lost more than a few seconds of typing.
Shutting down and restarting up again put me where I was before, state of editing buffers all saved in the swap file. When I was at a suitable stopping point, then I would "save' to keep a good copy (yes, this was actually "overwrite").
Moving to MS-Dos and "office suites" was demanded by customers for interchangeability, but I've always felt I lost a lot when moving away from FinalWordII.
(Score: 0) by Anonymous Coward on Wednesday December 21 2016, @08:10PM
But you should still be able to save. Because if you don't do the save but the system does it unpredictably you aren't always sure what version of the document was actually saved. More so if the system crashes or similar.
e.g. you are in the middle of a change that should be "atomic" and the system saves and the power goes off. Now your document is in an inconsistent state. Of course if you use version control you can rollback etc, but we're talking about normal folk.