It's such a misleading title. It's nothing like Dropbox.

We're talking about 60 lines of python for the "server" and 90 lines of python for the "client".

That's a weekend hack, not a Dropbox clone.

It happened so many times in the past, that I'm patenting a method of getting on first page of HN:

1. Write something

2. Call it a dropbox clone

3. Congratulations, apparently no-one bothers to check if that "something" does anything even remotely similar to dropbox:

- does it have a GUI client with a highly polished interface?

- does it have an installer?

- does it have conflict resolution to reconcile changes made on different computers?

- does it try to not corrupt files if download/upload fails in the middle?

- is it self-contained or do you first have to install, say, python interpeter?

It's not even rsync yet alone dropbox!

It looks like this doesn't work with folders... or have some kind of hash to detect alteration. While I appreciate you sharing the project, this is probably premature at this point.

Here are somethings that I would consider adding:

    * a README  (update: done! :) )
    * consider making this work with virtualenv by default. This way you can install
      Flask as a library without making me install it for the system. Adding a short
      bash wrapper script really helps here.
    * support for folders
    * sha1 hashes to ensure your files are consistent
    * de-duplication of chunks would be a good thing to add too
    * The way you are sending data now looks like you are using GETs for everything. 
      If you are really going to make this work, you should use GETs for downloading and PUTs or POSTs for uploading.

Yes, this is still very premature, and more of a learning project for me.

I know about no support for folders, I didn't have time to fix that yet, but I will!

Virtual enviornment is interesting, I will look into that.

* It does check for alterations actually then uploads the altered file, look at the main loop in the client.

The way I am sending files now is awful! I plan on fixing all thos, thank you for the response. :)

Good luck to you. I hope that you come up with a worthwhile project that you can learn a ton with.

But, you it probably shouldn't have been submitted to the wolves in this state :).

Haha, thank you sir! And don't worry, I take pleasure in feeding the wolves. :p

As soon as I clicked the source and didn't notice a binary diff being done for files I realized it was a toy/learning project, but my reaction was "Hell yeah!" anyway. Keep it up.

If you can explain in the readme how to set this up for first usage it would great.

I will add that in the next update.

os.system("touch files/"+file)

Oops. What if my file is called " && rm -rf ~"?

I know it is a fresh project but a README would be really cool to have.

I know, I'll be honest I just uploaded it to Github and thought it would be a good idea to share! I will add a README.

Put a LICENSE on there too.

This has some fairly serious security issues, which is fine for a something not designed to be seriously used (or at all). However, the readme implies you could use this and your files will be safer than with some third party. Which is dangerous, to say the least.

I'll outline a few obvious issues I see:

- No explicit protection against directory traversal attacks (../../etc/passwd type stuff) on upload and download.

- Shell command injection on the file name on upload.

- Naive authentication. - Unsalted, fast hash sent in the URL. - Password stored in clear text server side.

- No transport security (HTTPS).

This is cool as a interesting project to work on, but it should be made clear not to use this for anything just yet.

>- Naive authentication. - Unsalted, fast hash sent in the URL. - Password stored in clear text server side.

I don't understand the point of hashing the password in the client anyway... The hash is as good as the password to an attacker.

Sure is!

It would be possible to use a challenge response authentication scheme (http://en.wikipedia.org/wiki/Challenge%E2%80%93response_auth...) but just doing things over HTTPS is generally fine.

You have to realize this is a very early release! The first working release! I Didn't take anything else into consideration, but I will. Thanks for the comment :D

The author needs to rid himself of using any os.system post haste. Just say no.

I know, I was in a rush! I didn't have much time and I needed to put this idea into action, I realize it isn't the correct way of doing it :P

Your server request handlers could use decorators for checking if the user is logged in.

Here is an example decorator: https://github.com/kamalgill/flask-appengine-template/blob/m...

In use: https://github.com/kamalgill/flask-appengine-template/blob/m...

    urlopen(self.url+"/list/"+self.username+"/"+self.password)

>.<

What?

Basically you need to run this over SSH or SSL to obtain any kind of security. Dropbox has security out of the box.

Dropbox also has: A GUI, a website UI, conflict resolution, support for folders, local sync. The list goes on.

As others say, this is very, very, very immature and incomplete.

I'd rather use Dropbox. Or `rsync`.

I'm surprised no one commented about ownCloud yet -- like a locally (or privately hosted) dropbox clone with extra features to boot.

for efficient diffs, I suggest the author (and anyone else who cares to explore having an efficient diff based backup of lots of data) look into rolling hashes. great way to split data into chunks that are robust against insertions in the middle of a file! (uniformly splitting a file every X bytes means you resync the entire file after an insertion!)

Should have the client use fnotify or similar.

I was thinking an appropriate solution would be watchdog:

https://pypi.python.org/pypi/watchdog

Maybe an option to use HTTPS?

Yes, that would be nice.