241–250 of 296 posts
Another Dropbox horror story: My colleague lost most of his Dropbox folder last week, and wasn't able to recover everything. What happened: he had Dropbox synced to 2 computers, but one of them hadn't been used in a while. He turned on the old computer, and apparently, for some reason, Dropbox decided that the fact that many files weren't there was because they were deleted. Of course, the files weren't there because…
Earlier quoted context omitted.
OK, let's take a look at your points: > I'm not sure knowledge of an obscure Windows-specific drag and drop quirk should be a requirement for using Dropbox safely. Not a "obscure Windows-specific drag and drop quirk". This is how the OS works. If you are a developer you need to know your OS. > I'm not sure use of a partition table editor should be a requirement for using Dropbox safely. It isn't, but if you are smart…
Out of curiosity, when storing new files how do you decide between Data and Development drives or is Data fully unrelated to Development context?
I own more than one business and we also do work for other businesses, so, generally speaking, the "Data" drive holds business data partitioned-off into appropriately-named directories.
I also have what I call "support" directories there. For example, I have a "SolidWorks Support" directory with models, macros, tools and other items that are there to support work with that software. The same is true of Photoshop, Altium Designer, Web Design and other segmentable tasks.
Then there's more mundane stuff, like "Digital Photography", "Personal", "Scans", "Temp", "Outlook Data", etc.
Projects started to kind of pollute the data drive in some form. Also, the directory hierarchy started to become a little crazy. For example:
D:\\Projects\\Design\Mechanical\\Suppliers
D:\\Clients\At one point I thought that I should segregate active development from finished or shipping product. In other words, make a distinction between "project" and "product". That's why I introduced the "Develpment" drive.
There's another reason. When doing FEA thermal and/or flow simulation for various projects the Data drive started to become clogged-up with simulation data. As you navigate through many iterations of design ideas and simulations you can easily fill-up gigabytes. I didn't think that this belonged anywhere near the "Data" drive.
Finally, some tools (Xilinx ISE back then) did not take kindly to paths with spaces. So I always had to have a separate folder for Xilinx projects which has always bothered me.
This "Development" drive now allows me to create a simple folder with a short path:
Z:\ProjectA
I also have an "xampp-sites" folder on there for web projects. The projects can live in their own directories in the "Development" drive:
Z:\TheNextFacebook
Z:\TheNextGoogle
Once a "project" graduates to being a "product" it is zipped-up and copied or moved into a "Products" folder under the appropriate company directory in the "Data" drive. As an example, if we are talking about an iOS project it turns into a product once it is submitted to the app store and approved.
The jury is still out on whether or not this is a good idea or simply a reflection of being insanely anal about organizing data. I don't know. I am always open to new and interesting ideas on this front. I try to think of the "Development" drive as a dirty or work drive of sorts where I can mess with a lot of things without polluting the "Data" drive. I have this implemented in one machine and have not been compelled to do so in other machines yet. Still thinking about it.
Note, the hardest part, here? is that you are one of the entities. It's very hard to design a system where a hostile entity compromising owner credentials can't lead to data loss.
Best I could think of would be a service that keeps your data available in read only mode for a certain period of time (for which you pre-pay) - but I don't know of anyone offering such a service.
I suppose a stack of blue-rays in a safety deposit box would come dang close; I mean, sure if /all/ of your credentials were compromised you are still screwed, but if they can impersonate you in person at the bank... well, that's a worse compromise than most people plan for.
Earlier quoted context omitted.
While I can't comment on this specific case, I do want to say there is a tremendous amount of rigor (and layers of protection) to ensure the end clients are resilient to misbehaving computers and do the right thing. For example, you shouldn't have to worry about the clock being accurate as it has no bearing on the final sync state. Just to dive in a bit for the HN crowd: We base the changes that should be applied to…
Client rigor doesn't help with server failure this severe. The guy lost everything because a temporary team membership was revoked. And now you're coming back to talk about your rigor, and how you catch things that fall through the cracks. This really comes off, to me at least, like LinkedIn did when after their breach and it was revealed they weren't even salting passwords, they tried to brag about their security, a…
Earlier quoted context omitted.
While I can't comment on this specific case, I do want to say there is a tremendous amount of rigor (and layers of protection) to ensure the end clients are resilient to misbehaving computers and do the right thing. For example, you shouldn't have to worry about the clock being accurate as it has no bearing on the final sync state. Just to dive in a bit for the HN crowd: We base the changes that should be applied to…
Client rigor doesn't help with server failure this severe. The guy lost everything because a temporary team membership was revoked. And now you're coming back to talk about your rigor, and how you catch things that fall through the cracks. This really comes off, to me at least, like LinkedIn did when after their breach and it was revealed they weren't even salting passwords, they tried to brag about their security, a…
Earlier quoted context omitted.
Dropbox engineer here. There should be a drop-down item to switch accounts: https://www.dropboxatwork.com/2012/12/easily-switch-between-... The first time you select 'Switch Accounts' you will be able to log in your personal account. After that, you will be able to switch accounts without having to type the other username every time.
I had checked before posting and there was no such option. I did manage to make it appear in the end but it required logging out as my personal user and then logging as the team account and then logging in as personal again. Why not just make 'Switch Account' always be present rather than having one blessed starting point account? The wording also implies this won't work if you have two team accounts.
Earlier quoted context omitted.
Seems questionable to use the local time for that. System time isn't exactly a trusted quantity, is it?
What other time source would you propose using?
If the time is just used to check for certificate expiration, maybe nobody considers it worth worrying about. Which I guess is fine as far as it goes... but the other day I couldn't get Dropbox to do its thing when my clock was only a few hours off. It didn't seem likely that an SSL date check was involved in that case.
Earlier quoted context omitted.
Client rigor doesn't help with server failure this severe. The guy lost everything because a temporary team membership was revoked. And now you're coming back to talk about your rigor, and how you catch things that fall through the cracks. This really comes off, to me at least, like LinkedIn did when after their breach and it was revealed they weren't even salting passwords, they tried to brag about their security, a…
Completely disagree. I found no problems with the tone here. Instead, you have an insider who shares a few implementation details to give us an idea about the depth at which they go to prevent data loss failures. I saw nothing in his post as "bragging". The guy lost everything because a temporary team membership was revoked. What would you like him to do, apologize profusely and robotically without knowing the detail…
If you had stopped there, I'd have said yes.
.
> To expect every employee to know details of every issue
I ... had no such expectation?