Watch while Expandrive destroys my data in this video.
2
people have this problem
I have this problem, too!
Tell me when someone solves it.
The more people who report this problem, the more it gets noticed.
The more people who report this problem, the more it gets noticed.
The best solution from the company
-
Hi Zach,
I’m really sorry you’ve experienced this problem. Data lose should never happen as a result of using ExpanDrive, and we take it extremely seriously.
Unfortunately, this is a known issue with CSSEdit that we have been unable to solve. Fortunately, CSSEdit is the only program known to be effected.
We’ve spent a lot of time and effort trying to solve this problem, but without success. We’ve emailed macrabbit four times looking for help in solving this issue, and never received a reply. Despite extensive testing, we’ve never even been able to reproduce the issue. On several occasions I’ve personally spend 20 minutes at a stretch doing nothing editing and saving files with CSSEdit on various servers, and I’ve seen the issue happen. Once we can recreate an issue we’re usually able to fix it within a couple days. If you’d be willing to share a workflow we can use that will reliably create the issue, we’d certainly be grateful.
In our own defense, it’s probably that the data loss isn’t ExpanDrive’s “fault”. There are a lot of things that a program can do to a filesystem object that will work most of the time, but that might not be safe to do all of the time. It seems probable that this is what’s going with CSSEdit. In particular, ExpanDrive doesn’t just delete data on the server for no reason. ExpanDrive responds to application requests to perform filesystem operations. In this case, it seems that CSSEdit does some test, get’s an answer it doesn’t like, freaks out, and might delete the file at its own request. It might be simply coincidence or luck that this doesn’t happen when editing a file on a hard drive. (Without help from macrabbit, we can only guess at what their code is doing.) Regardless, our policy is to make ExpanDrive work as well as we can with every program, even when the problems aren’t our “fault”.
Finally, your subject line seems a little alarmist. Again, I’m really sorry you had this problem. I’ll add an entry describing it to the top of our FAQ so that users will be aware that there is a problem with CSSEdit. But there’s every indication that this is an isolated issue with a single program, and it’s quite possible that ExpanDrive isn’t even the responsible party. I understand how frustrating data lose is, but it’s unfair for you to paint this as a malicious action on ExpanDrive’s part.
If you’d like to email us at support@expandrive.com, we’d be happy to answer any further questions, or work with you to try to solve this problem.
The company says
this solves the problem
-
Inappropriate?Hi Zach,
I’m really sorry you’ve experienced this problem. Data lose should never happen as a result of using ExpanDrive, and we take it extremely seriously.
Unfortunately, this is a known issue with CSSEdit that we have been unable to solve. Fortunately, CSSEdit is the only program known to be effected.
We’ve spent a lot of time and effort trying to solve this problem, but without success. We’ve emailed macrabbit four times looking for help in solving this issue, and never received a reply. Despite extensive testing, we’ve never even been able to reproduce the issue. On several occasions I’ve personally spend 20 minutes at a stretch doing nothing editing and saving files with CSSEdit on various servers, and I’ve seen the issue happen. Once we can recreate an issue we’re usually able to fix it within a couple days. If you’d be willing to share a workflow we can use that will reliably create the issue, we’d certainly be grateful.
In our own defense, it’s probably that the data loss isn’t ExpanDrive’s “fault”. There are a lot of things that a program can do to a filesystem object that will work most of the time, but that might not be safe to do all of the time. It seems probable that this is what’s going with CSSEdit. In particular, ExpanDrive doesn’t just delete data on the server for no reason. ExpanDrive responds to application requests to perform filesystem operations. In this case, it seems that CSSEdit does some test, get’s an answer it doesn’t like, freaks out, and might delete the file at its own request. It might be simply coincidence or luck that this doesn’t happen when editing a file on a hard drive. (Without help from macrabbit, we can only guess at what their code is doing.) Regardless, our policy is to make ExpanDrive work as well as we can with every program, even when the problems aren’t our “fault”.
Finally, your subject line seems a little alarmist. Again, I’m really sorry you had this problem. I’ll add an entry describing it to the top of our FAQ so that users will be aware that there is a problem with CSSEdit. But there’s every indication that this is an isolated issue with a single program, and it’s quite possible that ExpanDrive isn’t even the responsible party. I understand how frustrating data lose is, but it’s unfair for you to paint this as a malicious action on ExpanDrive’s part.
If you’d like to email us at support@expandrive.com, we’d be happy to answer any further questions, or work with you to try to solve this problem.
The company says
this solves the problem
-
Inappropriate?I can't believe you guys know about a bug with CSSEdit, and don't plaster it all over the product. "DO NOT USE with CSSEdit". About 90% of your customer base is web developers, indie crowd, and WE ALL USE CSSEdit!!!!!!
Even the persons who first told me about the product use it with CSSEdit all the time.
This absolutely explains me screwing up 3 server directories over the last few weeks. Can't believe I didn't figure out it was CSSEdit. What about macrabbit's espresso product?
Do you mean to tell me you can't get ahold of him? Did you try really hard, or just send an email to him casually? Because I can raise him, and I've tried for 10 minutes.
Either WARN customers, or get it solved. asap.
The problem likely comes from cssedit's live preview window, it very liberal in writing files to disk non-stop, with the data access, constantly, even when it's in the background, not being used it's going.
Please look into it, guys we're your core customers, this is probably happening to 50% of your customers right now, and they don't even know it. I promise if you warn them MacRabbit will hear about it asap, the design/developer community is a small crowd. -
Inappropriate?Court K -
I 100% agree with you. If you can get him on the horn, please help us out. We've sent 4 emails begging for a response.
We still can't replicate the issue over here - I don't think the problem is pervasive, but we're working as hard as we can to figure whose fault it is and fix it.
We'll figure it out
-Jeff -
Inappropriate?I had this problem a while ago and I have not used ExpanDrive since (also because I cannot change permissions still). I hope it is fixed soon.
I’m frustrated
-
Inappropriate?Is anybody able to replicate this issue using SFTP [port 22] - or is it isolated to FTP connections?
Thanks - we're working on it. MacRabbit WILL NOT respond to any emails. It's very very frustrating. -
Inappropriate?The instance recorded in the video was using SFTP.
-
Inappropriate?Can you verify which version of ExpanDrive you were running for the video?
Also - any information about the server you were connecting to would be helpful, as would the version of CSSEdit, version of OS X, etc. -
Inappropriate?Local Machine
Mac Pro
Dual-Core Intel Xeon
Processor Speed: 2.66 GHz
Number Of Processors: 2
Total Number Of Cores: 4
L2 Cache (per processor): 4 MB
Memory: 8 GB
Bus Speed: 1.33 GHz
Boot ROM Version: MP11.005C.B08
Local OS
Mac OS X Version 10.5.7
Local Apps
ExpanDrive 2.0.2
CSSEdit 2.6
Remote OS
Linux 2.6.18-128.1.10.el5 -
Inappropriate?Can you get the SFTP server version by running telnet server.com 22
it'll spit back the server string then disconnect you.
Does this happen with all CSS files, does it matter if you set your remote path to a particular folder? We're trying to isolate this down as far as we can. Thanks Zach. -
Inappropriate?SFTP protocol version 3
(using a port other than 22)
This does not happen with all CSS files. I'm not sure if remote path has anything to do with it. I have been using Expandrive + Textmate + CSSEdit combination for a little over a year, and this is probably the 4th or 5th time this exact thing has happened with CSSEdit (all occurrences have been since the Expandrive 2 update). Although I have had periodic issues with file corruption. (e.g. files getting shuffled together haphazardly) with Textmate and BBEdit.
I wish I had more details, but to be honest, once I isolated the cause I was more interested in immediately ending this behavior and preventing data loss than reproducing the scenario. I just happened to be shooting some screencasts for something else at the time, so I was able to get it on tape.
That said, here is some information that may be helpful:
I tried to modify the exact same files with Textmate and BBEdit. Textmate crashed altogether and BBEdit gave permission warnings and would not let me save.
Also, the directory I had mounted with Expandrive as user: harkeynet was originally created and owned by root:root. I shut Expandrive and CSSEdit down and chowned the files to harkeynet:psacln. After this, I mounted the drive with Expandrive and performed the exact same file procedure in the video without further incident. -
Inappropriate?New video of files getting wiped
http://tinyurl.com/mon62s
This time it occurs with the default Mac TextEdit application CSSEdit is not even open.
It is currently 2009/07/14 @ 11:42AM EST
The drive is still mounted. I can reproduce the issue right now if any of the Expandrive guys wants to screenshare or anything. I can set up a GoToMeeting or whatever.
I will stand by as long as possible.
My AIM handle is zachharkey
My Phone number is 404-561-1124
I’m losing money.
-
Inappropriate?Thanks Zach - just left you a voice mail. Can you email support@expandrive.com when you get a chance?
-
Inappropriate?Eeek this is pretty scary. Looks like there are still some permissions gremlins in this package.
-
Inappropriate?This problem is marked as solved?? What is the resolution?
-
Inappropriate?For what it's worth - we don't use get satisfaction anymore. It makes us select stupid things like "this is the best solution" - then says it is solved.
-
Inappropriate?Ahh I see. Is there an interactive forum of any sort or just direct with support?
-
Inappropriate?We just released ExpanDrive 2.0.4b1 on the auto updater, which provides a workaround that prevents data loss using CSSEdit.
The issue roughly works like this - in hosting environments that have nested filesystems [such as a path that is a nest NFS/ZFS mount point], older version of OpenSSH based servers will not correctly rename a file using absolute pathnames when a pathname contains components from two separe filesystem. Due to limitations in the SFTP protocol, in order to rename a file over top an existing file [which is what CSSEdit does], you first need to unlink the target file. When the rename unexpectedly fails due to this server bug, the original is lost.
The fix provided in 2.0.4 will ensure that the original file contents are preserved under the original name. However, there is no way for us to provide a workaround so that saving works correctly - you will need your provider to update their server software. Please report back with any input you guys have, thanks so much for working with on this issue.
I’m happy
Loading Profile...



EMPLOYEE

EMPLOYEE
