Jump to content

Recommended Posts

Posted

Hey guys!

 

Name's Evan, im currently studying in AUEB , in the computer science department.

 

So, a teacher gave me an assigment to create a simple updater program in java.

I would like to discuss with you, which is, in your opinion the best algorithm to use.

 

I have a beta version of the program ready.

 

It includes :

  • Basic ftp utilities (download file, delete file , upload file , etc)
  • A basic login panel , which uses text files as a database(the passwords are decoded and encoded with Ceaser cipher's method)

I wont keep it that way its just for test purposes

 

As for the update part, i thought about it like this :

 

1)Split the file on the server and the file in the local working directory into parts

2)Check each part seperately  (byte by byte) 

3)Keep track of the parts that changed

4)Delete the changed parts in the server, upload the updated ones and join the file back together

 

The problem is :

 

I have no permission to split/join the file in the ftp server....

Or at least i havent found a way yet...

So im trying to find a fast way to proccess the update, without having to download the file from the server in order to check it...

 

Thanks for your time.

Waiting for your opinion 

Posted

You can't access the bytes of a file till you download it, the FTP is gonna provide you only with a link and filename, in order to access the bytes you must download the file first and that will make your updater really really bad cause it will be dumb.

 

Play with MD5 hashes of the two files

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


  • Posts

    • TG Support: https://t.me/buyingproxysup | Channel: https://t.me/buyingproxycom Discord support: #buyingproxy | Server: Join the BuyingProxy Discord Server!  Create your free account here
    • I think you should check the video more carefully you missing something very important 😛      
    • Im responding to an anonymous account with 3 posts, almost no background, and practically zero useful information added to the discussion. On top of that, the topic title is misleading  calling it "Lucera Source Code" gives a completely different impression from what is actually being presented.   I didn’t say anything different. Therefore, I have no clue how his process produces the same desirable result.   And here you are creating drama. Your topic title clearly says "Lucera Source Code," which is not actually the case, or at least that’s how it looked when I first clicked on it, so I don’t think I was completely off. There’s also no significant information about your process like  what difficulties you faced, what tools you used, or anything else meaningful. Yet you still expect others to provide value based on what? I’m not talking about your project itself which, by the way, good job. I’m talking about the topic itself as a source of value for this forum, because right now it doesn’t really offer much in that regard. So regarding the semantics, yes, wording does matter.  
    • You are funny guy! 😄 😄 😄    I was working with Lucera long before “AI apps” became fashionable. This was not something I generated in one day with a prompt. It took me years of work, testing, debugging and fixing broken decompiled code.   Of course a decompiled source is not the original private repository with the original comments, history and developer structure. Nobody said it is the same Git repository. But saying it is only “guesses” is also wrong.   When you decompile, rebuild, fix thousands of compile/runtime issues, restore broken logic, reconnect scripts, fix bad casts, repair database calls, compile it again and run it in-game, at that point it is no longer just a guess.   It becomes a working reconstructed source base!   The important part is not whether it is byte-for-byte identical to the original private source. The important part is that I can now work directly inside the code, change core logic, rebuild scripts, fix bugs and continue development without being locked behind closed binaries.   Does it compile? Yes. Does it run in-game? Yes. Can I modify core systems directly? Yes. Can I continue development independently? Yes.   So call it reconstructed, decompiled, cleaned, restored or whatever name you prefer. The result is still the same: I have a working source environment that gives me control over the lucera2 project.   And that was exactly the goal!   🙂 
  • Topics

×
×
  • Create New...

Important Information

This community uses essential cookies to function properly. Non-essential cookies and third-party services are used only with your consent. Read our Privacy Policy and We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue..