Ticket #77 (closed Defect: fixed)

Opened 3 months ago

Last modified 2 months ago

My project directory was erased

Reported by: ats Assigned to: isak
Priority: High Milestone: 1.2.5
Component: main Version: 1.2.4
Severity: Normal Keywords:
Cc:

Description

When running makepackage on my project, the whole project was erased from the disk!

Project home directory: /proj/FileWorkBench After

cd /proj/FileWorkBench
makepackage

the directory has been erased. What's going on!?

This is my main source directory. Luckily I had backups from yesterday, for all but one directory. But only that directory represents many weeks of work.

That a tool erases whole directories like that without any confirmation is quite serious.

I'm working at restoring my files on EXT3 file system now.

I attach a log from the session.

Regards // ATS

Attachments

autopackage-erase-all.txt (1.0 kB) - added by ats on 04/25/08 13:07:09.
erase.diff (0.8 kB) - added by Jan-Nik on 04/27/08 14:30:11.
cleanup.diff (0.6 kB) - added by Jan-Nik on 04/27/08 16:20:09.
safe.diff (2.1 kB) - added by Jan-Nik on 05/07/08 10:14:06.

Change History

04/25/08 13:07:09 changed by ats

  • attachment autopackage-erase-all.txt added.

04/27/08 14:29:56 changed by Jan-Nik

Somehow your build_root was the same as your project directory. Don't know why, but here's a patch which makes the check, that $build_root is set to the current directory more robust (instead of only checking $build_root != ".").

04/27/08 14:30:11 changed by Jan-Nik

  • attachment erase.diff added.

04/27/08 15:12:14 changed by ats

Yes, that's right, $build_root was pointing at my project dir (I was having problems getting makepackage to find any files at all, so I tried that).

Spent two full days on grepping my /dev/sdb1 (extracting all strings to giant files on a separate disk). Then searching for fragments of known files... The missing source dir is back in place again. Sigh of relief.

I applied the path and on running it I get:

The meta package is 'fsect 1.0.package.meta'.
The complete package is 'fsect 1.0.package'.
The Luau repository XML entry file is 'myproject.xml'.
/usr/bin/makepackage: line 267: cd: : No such file or directory
/usr/bin/makepackage: line 267: cd: : No such file or directory

$build_root is set to '.' from the the spec file. It's empty here?

Regards

// ATS.

04/27/08 16:19:54 changed by Jan-Nik

Hm... Don't know why.

I think as all these directories are starting with apkg- (and are therefore deleted anyway), cleanUp shouldn't explicit delete them (right grammar?).

Here's a new patch which simply doesn't delete the directories, but there shouldn't be any left-overs nevertheless.

04/27/08 16:20:09 changed by Jan-Nik

  • attachment cleanup.diff added.

04/28/08 06:36:39 changed by isak

  • owner changed from taj to isak.

Ouch. Nasty thing. Glad you got your stuff back!

We should definitely check more rigorously before cleaning up stuff. The problem is, we can't guard for every possible setting of $build_root (and other variables) I mean, setting $build_root to /usr or /home would be devastating.

I'm gonna look into applying erase.diff into svn. That's on check we should do at the very least.

04/28/08 14:31:13 changed by isak

  • status changed from new to assigned.

erase.diff applied in r2442. Can we close this as fixed?

04/28/08 14:46:20 changed by ats

Hello,

What was needed to trigger this was to set both of $build_root and $source_dir to point to the same directory (like /home/ats/MyProject).

I haven't tested the patch but just setting the variables as above would trigger it.

Wouldn't it be possible to store the name of any created directory in a variable? (when doing mkir, put it in an array of dirs to be removed at cleanup).

For me, you can close if the patch is tested and found working.

Anyway, thanks for investigating the issue.

BTW, when this happened, I was experimenting with a very simple setup: no build step, just copy files from the current directory. The solution was to set $build_root='.' A simple sample like that would be appreciated (no configure, no build, just copy files).

Regards // ATS

04/28/08 17:47:50 changed by Jan-Nik

Hm... although i wrote erase.diff I don't think it really fixes this issue. IMO cleanup.diff is the better patch (explained in my previous comment).

Let's assume the user changes $build_root to /home/<user>/ and his project is in /home/<user>/<project>/. makepackage would then delete the whole home directory!

If a user sets the build_root himself, he knows what he's doing and should cleanup himself. Deleting anything else other then /tmp/apkg-* directories will always be a security risk i think.

04/29/08 02:06:28 changed by isak

The problem with cleanup.diff is that it removes all cleanup functionality, and we don't want that.

I have also been thinking along the lines of anything-not-in-$TMP shouldn't be deleted.

Maybe (pseudo code):

# Resolve any symlinks, relative directories and strip trailing/duplicate slashes etc.
$build_root = get_canonical_path($build_root)
# Whack it if it's inside $TMP
if $build_root.StartsWidth($TMP) && $build_root != $TMP then
   rm -rf $build_root
end if

I will cook up something this week unless you beat me to it Jan Niklas :)

(follow-up: ↓ 10 ) 04/29/08 07:27:54 changed by Jan-Nik

But doesn't this line at the of CleanUp? do the job? rm -fr "${TMP}"/apkg-*

(in reply to: ↑ 9 ) 04/29/08 17:09:19 changed by isak

Replying to Jan-Nik:

But doesn't this line at the of CleanUp? do the job? rm -fr "${TMP}"/apkg-*

It does. Didn't notice that line was there.

05/07/08 10:11:42 changed by Jan-Nik

  • milestone set to 1.2.5.

Okay here's another patch, which checks if the directories are starting with ${TMP}/. Although I think cleanup.diff is okay, too.

I also changed CVS to SVN where is it mentioned in makepackage. (Completely different thing, sorry i was too lazy to create another patch)

05/07/08 10:14:06 changed by Jan-Nik

  • attachment safe.diff added.

05/11/08 05:01:58 changed by isak

  • status changed from assigned to closed.
  • resolution set to fixed.

Ok, safe.diff looks good - applied in r2447, Closing as fixed.