Major problem after project rename and clean build #91
Comments
|
This sounds really bad. |
|
Jantje - thanks for the quick reply. I renamed the project without specifying a path; I simply right clicked on the project name and selected "Rename…". I don't really want to try and reproduce the error, but I can tell you selecting clean build definitely tried to delete everything from / on down on my machine. I did it twice until I figured out what was going on. The project is attached. On Dec 1, 2013, at 5:49 PM, jantje [email protected] wrote:
|
|
I'm sorry but I can't find the attachment. On 01-Dec-13 23:54, Thomas Sasala wrote:
|
|
it seems it won't come through with email and i can't attach a zip file through the web site. do you have an area i can drop it? |
|
I have no public area to drop files. Normally mail should do for source code. How big is it? Have you compressed it? |
|
It's 12K zipped. I uploaded it to my website but I don't necessarily want to publish the URL here. On Dec 2, 2013, at 8:09 AM, jantje [email protected] wrote:
|
|
12K should fit the mailbox. |
|
I finally had some time to look at the zip but .... |
|
I'm closing this one as a one off. |
|
Feb 3, 2015: I just had the same thing happen to me on my Mac. (OS X 10.10.2) Eclipse stable version (V2.3_mac64.2014-07-12_02-06-35.tar.gz). I was fooling around trying to get Serial to read for Arduino, by adding a couple of directories. Finally tried to do a build clean and both fans went on and things seemed to freeze on the bar-graph. I changed to see the other view and watched as it rm'd file after file. Half my Applications were deleted from /Macintosh HD/Applications along with G*d knows what else. By the time I looked, it was working on removing files in /Xcode directories. |
|
I'm sorry you had this very annoying problem. Some background info. CDT uses make to build the code. Make is a command line tool. To clean the project the "rm" command is used. if the command is changed to "rm /" your whole disk will be whiped (that is when you have the right to do so). Also if the command is preceded with "cd /" again your whole disk will be cleaned. |
|
Hi, |
|
As both reporters work on mac it may be a mac related issue. I have a mac at my disposal next week so I'll give it a try. @freebs Not related but in response to your comment. |
|
Hi, it's taken so long to get back to you with an answer. This was a new install (though I had previously downloaded v2 and tried that, I was having trouble with versions of Arduino vs the Eclipse IDE and had downloaded different combinations) I did rename some items, but only using in-editor functionality, not from the operating system side. While I had tried builds, they were mostly failing because of libraries not found... which is why I was trying the combinations of things to add to the search paths. When all the builds kept failing I came across the 'build new' and thought that would 'flush' any possible old files and redo from new. Thanks for the tip above. I'll give that a try. |
|
I don't know what to do with this issue. I'm sure it is a genuine request but it also seems to hardly ever happen. |
jantje
added
importance: usability
status: no good solution found (yet)
|
I've seen it as well on OS X 10.9 and the v2.3_mac64.2014-07-12_02-06-35 stable package. Did a simple verify, clean started running, and next thing I knew it was trying to delete everything in /Applications. It may have been doing in / and just got /Applications first. Dunno. I'll try the plugin on a Linux VM... |
|
If there's a way to generate the build instructions without executing them, I'm willing to try that as a means of helping diagnose what is happening. |
|
I think that for one reason or another the rm-rf command is executed in the root. To investigate this issue you could change the rm -rf command.
Some background info. The ArduinoGnuMakefileGenerator.java is a copy of GnuMakefileGenerator.java delivered by CDT to allow the plugin to work. I have just compared the current version of the files and all seems well. (read no changes in CDT) String cleanCommand = "rm -rf";the cdt code is String cleanCommand = config.getCleanCommand();
try {
cleanCommand = ManagedBuildManager.getBuildMacroProvider()
.resolveValueToMakefileFormat(config.getCleanCommand(),
EMPTY_STRING, WHITESPACE,
IBuildMacroProvider.CONTEXT_CONFIGURATION, config);
} catch (BuildMacroException e) {
}I can't recall why I decided to hard code the command. As I find nothing on CDT having this issue; it is probably related to my changes. private StringBuffer addMacros()I moved buffer.append("-include subdir.mk" + NEWLINE); from after to before this block of code List<String> subDirList = new ArrayList<String>();
for (IContainer subDir : getSubdirList()) {
IPath projectRelativePath = subDir.getProjectRelativePath();
if (!projectRelativePath.toString().equals(""))
subDirList.add(0, projectRelativePath.toString());
}
Collections.sort(subDirList, Collections.reverseOrder());
for (String dir : subDirList) {
buffer.append("-include " + escapeWhitespaces(dir) + SEPARATOR + "subdir.mk" + NEWLINE);
} |
|
Thanks for the details. It may be a couple of days before I can get back with info as I'll need to setup a build env. for the Arduino Eclipse plugin in order to investigate. |
|
read the read.me file on how to setup an environment. piece of cake thanks to wim :-) |
|
Piece of cake to get launched, but didn't finish mvn verify -Pmac64,mars |
|
mvn verify -Pmac64,luna |
|
Okay, I'll build with Luna. I was trying to use Mars since that's the version of Eclipse I was using when the dirty deed (rm -rf /) occurred. |
|
Please file an issue and assign to me. Sent from TypeMail On Jul 18, 2015, 16:36, at 16:36, jantje [email protected] wrote:
|
|
I edited ArduinoGnuMakefileGenerator.java to use a shell script in place of "rm -rf". Here's the command generated when I did a "clean" for the project. Now I reconstructed the project and so it would seem that this time around, the dirty deed of "rm -rf /" is not (yet) occuring. I'll try a few more things. Also, RM.sh logged the current working directory. It wasn't / . It was a subdirectory of the project directory as expected.. make clean |
|
Good work. |
|
Well, for your amusement, here's the protective script which is run in place of "rm" when a clean is done. It should catch any bad behavior. |
|
I feel you will find the problem :-) |
|
Well, it is trying to delete something spurious, the very last item "RepRapFirmware". No such object exists and I'm unclear of why it's trying to be deleted. But I have an inkling of where it might have come from. Namely, "RepRapFirmware" is the name of the project. As in ProjName == RepRapFirmware. And, under the Project Preferences, I spy in C/C++ Build > Settings > Build Artifact a mystery artifact shown as having no artifact type (it's blank), an artifact name of ${ProjName} with no extension or output prefix. I didn't put that artifact there; it must have come from when I made the initial Arduino Sketch? (I made a new sketch then imported all this RepRapFirmware goodness into it after first purging it of stuff which arguably shouldn't have been in the repo in the first place -- .metadata/, .settings/, etc.) Now, I have no idea how that artifact arose. But I'm am wondering if the "clean" is trying to remove artifacts and thus is doing a "rm -rf ${ProjName}" and hence the mystery "rm -rf RepRapFirmware" shown below. (Again, no such object exists.) And if that is the case, then I have to wonder if in my previous encounter, I somehow had a mystery artifact which was "/". |
|
I just looked at the makefile in a workspace of mine -a project called zero- and I see something I don't like
It looks like zero (the project name) is hardcoded in the clean command. That must be where your RepRapFirmware comes from. |
|
I looked at the code and did some tests. |
|
Has this ever happened again to anyone? |
|
I made sure that the plugin ran a shell script rather than the actual rm binary. Via the shell script, I protected myself against it happening again and I don't rightly know if it did happen again.... When it was happening, it was repeatable. In the brief time I continued to use Eclipse -- I've never cared for IDEs -- I do not know offhand if it again occurred. I've since moved the project to a command-line based build environment and removed Eclipse and the plugins. |
|
I don't know if this was ever suggested but if the variable substitution does not work then rm -rf {project}/{configuration} becomes rm -rf / |
|
This has been open for a long time so I did some rereading to freshen up. bash-4.1$ rm -f / |
|
@wimjongman |
jantje
added
status: fixed in 2.4
and removed
status: no good solution found (yet)
|
removing the r does not fix the problem; it just stops directories from being deleted. if the parameters are null, it will still delete all regular files in the root directory without asking. Secondarily, it will no longer remove the subdirectories in the build area as intended during a clean build.
|
I think it does
the r stands for recursive all subdirectories. So without -r rm can never do again what OP reported "it attempted to remove everything from my computer."
Can you be more specific, I mean: on a command line; parameters can not be null. IMHO To delete all files one needs to use wildcards (which has never been reported as happened) or remove a folder (recursively) which the fix makes impossible to happen.
Have you checked the logs above and the actual behaviour of the cdt? The pre fix behaviour does not remove the folders. |
|
Jantje - As far as I know, the -r flag recursively removes all files regardless of type. -f merely surpasses warnings and forces a remove if the user has the appropriate permissions. So, removing the -r allows any appropriately permissioned user to remove all regular files from the specified directory but does not allow the user to remove the directories. In the case of this specific failure mode, the input parameters are null, or blank as CDT interprets them. Which results in an "rm -rf /" command rather than rm -rf {project}/{configuration}” as intended. So the recommended change will issue a command that will remove all regular files at the root directory that the user is allowed to remove by executing “rm -f /“ when the input parameters are null/blank. In some cases that results in nothing being removed, in other cases that may comprise important things in the root directory. The recommended changes does not get to the root cause of why the parameters are null (or blank). There is no possible regex-style rm function that will operate correctly when the parameters that set the base directory are blank or null. I believe Dan has already proved under certain circumstances the operation does not perform as intended. I have not been able to reliably reproduce the parameters that lead to the error. I think Dan or Will have but I’m not entirely sure. I’ve been following your project for a long time and I’ve been using it for even longer. I know it’s a lot of work keeping the plugin going and operating properly with the very dynamic nature of the arduino platform. However, simply closing the issue when the root cause has not appropriately been identified or remediated is fairly shortsighted in my mind. I’m pretty sure at this point you will suggest I dig into the code and fix the issue myself - trust me, I have tried without any luck. I happy to try again. -Tom
|
Thank you for your nice words. A real motivation to keep going. |
I propose you dig in the cdt code as it is probably a cdt issue or maybe even a eclipse issue. I will now lock this conversation because this conversation has caused to much harm to the plugin without any proof this actually ever happened. And with the -r removed it can no longer happen. I know this solution is more a work around than a 'solution as you are used of this plugin' but there are only so much things we can do. Best regards |
I just tried to rename my project and then recompile. The recompile did not work so I cleaned all. The plugin proceeded to execute "rm -rf /". I guess it intended to remove the release folder, but something was missing and it attempted to remove everything from my computer. It started with the Applications folder and made to it to the calendar app before I figured out what was wrong. Fortunately most of the files were owned by root preventing the remove from working properly. It did manage to delete the arduino application but I'm not sure what else. I'm happy to zip up the project directory if you want; the .cproject file looks like the {project.home}/Release was deleted from the build tools.
MacOS 10.8.5
Eclipse IDE for C/C++ Developers
Version: Juno Service Release 2
Build id: 20130225-0426
Arduino eclipse extensions 2.1.0.4
Eclipse IDE for C/C++ Developers 1.5.2.20130211-1820
Subversive SVN Connectors 3.0.0.I20130122-1700
Subversive SVN Team Provider 1.0.0.I20130122-1700
SVNKit 1.3.8 Implementation (Optional) 3.0.0.I20121228-1700
The text was updated successfully, but these errors were encountered: