Despite primarily being a windows user, I am a huge fan of rsync. Now, I don't want to argue the virtues of rsync vs any other tool...this is not my point.
The only way I've ever found of running rsync on windows is via a version that is built to run on top of Cygwin, and as Cygwin has issues with Unicode, so does rsync.
Is anyone familiar enough with the workings of rsync to say if there are any real technical programming hurdles to porting rsync to a native Win32 binary?
Or is it maybe that there has just never been enough interest from windows users to care to port it over?
Partly I ask because I'm am considering trying to take on the task of starting a port, but I want to make sure there's not something I'm missing in terms of why it may not be possible.
The way that windows locks open files might cause an issue requiring you to hook into the Volume Shadowcopy Service.
About two years ago this fellow ported the algorithm to C#. I haven't taken a look at the code (or the provided binary), but it might be a place to start looking or someone to try contacting.
http://www.russiantequila.com/wordpress/?p=8
I've been evaluating an effort to undertake a win32 port as well. I don't believe anything major would block it, but evidence from both the rsync mailing list and another discussion points to a heavy reliance on unix fork() system calls. Using threads appears the way to go for win32.
Threads vs. Fork discussion
(disclaimer: i promise, i don't google myself, but google analytics brought me here)
i went through porting rsync to .net (sig11's link is my blog). there are no technical hurdles, just practical ones. as was already said, the code is rather... dense. difficult to follow, and complete lack of comments. i'm more than happy to make my work available, but unfortunately, since it was part of a commercial effort, it's not in significantly better shape.
i have, on a number of occasions, messed around with the idea of reverse-engineering the protocol and doing a ground-up implementation that's wire-compatible with the existing one, but ... a bit cleaner to work with. i've even started a wiki to that effect, but... as you can see from the lack of contents there, other item have taken priority. if anyone would like to work with me on this, that may be the impetus i need to get going.
the concept of the tool is great, as is the functionality it offers, however it's rather limited outside the *ix space, and could definitely benefit from an api.
wiki link for reference:
http://www.russiantequila.com/wiki/index.php?title=Main_Page
Have you seen this:
http://www.itefix.no/i2/taxonomy/term/39
I have used cwrsync without any problem (and with the much of the usual cygwin misery), but I haven't had any need for unicode filenames, so I've not seen that problem.
I don't really know why there isn't a native Win32 port, but I did look at the source a while back because I implemented a similar delta-copy system in C#. As one would expect from the world of brilliant *nix hackers, the source is largely single-character variable names and a total absence of comments, which isn't terrible helpful and might be rather off-putting to would-be porters.
I would really appreciate a port of rsync to MS-Windows such that it can be built using Visual Studio. I am encountering various protocol errors at random, somewhat intermittently. I am using rsync to distribute sw to a grid of around 200 machines and typically get around a a dozen failures. I am using GCC 4.4.2 and the latest cygwin to build rsync v3.0.7. It would help me alot if I could experiment with a version that does not require cygwin. This is because the machines in the grid already have another cygwin-based app running that is a different version to the one I have.
Having spent some time on the rsynv mailing list opinion seems to be divided as to cause of protocol errors on MS-Windows. Some say it is a bug in rsync where it failed to do a clean socket shutdown, a bug that was fixed a while ago. Others say that it is a fundamental protocol error in rsync where the client does not tell the server that it is finished, it just shuts down, causing MW-windows servers to get a RST signal on the socket, something that does not happen on Unix.
Related
I need to build a file/folder tree with associated file icons and special locations like network computers.
Currently I'm using Shell API to achieve it: SHGetFileInfo, IShellFolder.EnumObjects and other functions.
It works fine most of the time, but occasionally, on customer's machines it causes various errors like random access violations deep in system libraries. Analyzing bug reports, some of those seem to be a result of 3rd party shell extensions which are loaded to my app's address space when the Shell API is used.
I'm thinking to somehow avoid using Shell API and do the job another way. What are the other good approaches to build a folder tree?
If the problem really is due to faulty shell extensions then the only sensible approach, in my view, is to remove those shell extensions. Trying to work with the shell, but avoid using the shell API won't lead anywhere useful. In fact I think that the likely outcome is that your alternative code will be less functional. All for the sake of one user that won't fix their broken machine. That's a terrible trade off.
If explorer is also crashing then that is a clear indication that the problem is indeed due to shell extensions.
Having said all of that, you post makes me suspect that you have had bug reports from multiple clients. That makes your diagnosis much less plausible. The shell API is a complex beast and it is very plausible that your code is defective in some way. I suspect that you may be guilty of a case of diagnosis by wishful thinking. It's very easy, when facing a fault that is hard to reproduce and diagnose, to believe that your code is not to blame. If multiple clients are reporting problems then my bet is that the defect can be found in your code.
I'm probably missing something, because I don't hear anyone else mentioning this. But when I look at the process and file system modules I see a lot of Unix-isms that are unlikely to work on Windows. How is this going to work for Windows users? Windows users who never used Unix may not even realize which are Unix-isms, that are never going to work for them. I suppose this is really just a documentation issue, it would be nice to filter documentation based on Unix or Windows. Process.getuid() would be one example. Chmod would be another. Even SIGUSERn is there. (Vague memories of servers mysteriously shutting down.) I do have Unix experience from way back, but many will not have. I avoided Rails because it was slow on Windows, but I hear that node.js is smoking fast on Windows, so I'm hopeful!
Since version v0.6 (except the latest v0.6.9, big fs bug), Node.js has become a first class citizen on Windows. Because of this, it's my thought that most 3rd party modules will eventually support Windows. A lot of the major ones do now, Express.js most notably.
This will get better too. Some third party modules require the extra step of forcing the user to compile native C++ modules (NPM/node-waf automates this). However, in future versions Node.js will be ditching this for binary compatibility. The developers behind Node.js are trying very hard to emphasize a first class development experience that focuses on a pleasant developer experience across all platforms.
Admittedly, the Node.js experience will be better on OS X or Linux, but it's going to only get better on Windows. I highly encourage you to check it out if you haven't already.
I’m looking into multithreading, and GCD seems like a much better option than manually writing a solution using pthread.h and pthreads-win32. However, although it looks like libdispatch is either working on, or soon going to be working on, most newer POSIX-compatible systems… I have to ask, what about Windows? What are the chances of libdispatch being ported to Windows? What are the barriers preventing that from happening?
If it came down to it, what would I need to do to preform that portage?
Edit: Some things I already know, to get the discussion started:
We need a blocks-compatible compiler that will compile on Windows, no? Will PLBlocks handle that?
Can we use the LLVM blocks runtime?
Can’t we replace all the pthread.h dependencies in userspace libdispatch with APR calls, for portability? Or, alternatively, use pthreads-win32 I suppose…
Edit 1: I am hearing that this is completely and totally impossible, ever, because libdispatch depends (somehow) on kqueue, which can’t be made available on Windows… does anybody know if this is true?
Take a look at : http://opensource.mlba-team.de/xdispatch/
This project (and other third-party libs) brings libdispatch into platforms(windows, linux) other than macosx
https://github.com/DrPizza/libdispatch
The Windows equivalent of libdispatch, from my basic understanding of it, is the Concurrency Runtime for unmanaged code and a collection of technologies collectively known as Parallel Extensions for managed code. It appears to me that GCD maps pretty well to both of these, since they both abstract work units (or "tasks") in a similar way.
From a bit of research, it appears that there's already a fair bit of interest in a port, but that port would be a fairly drastic undertaking and might end up being basically just another implementation of the API and not actually sharing significant code with the original libdispatch. I did see some proposals to porting libdispatch to being based on the Apache Portable Runtime instead of POSIX which'd make it easier to make it cross-platform to Windows, but even this would not be an easy change.
Likely, this would be by no means a small undertaking.
I think that rather than libdispatch-on-pthreads and pthreads-on-Win32, or libdispatch-on-APR and APR-on-Win32, it might be better to implement libdispatch directly on the Win32 Thread Pool API. The good news is that the two APIs are similar enough that you could probably do the port yourself. The bad news is that there would probably be lots of corner cases where there are small semantic mismatches that make exact behavior hard to achieve.
At work I use ClearCase and SourceSafe, but have found some time to do some time to code for myself enroute thanks to a disposable laptop.
However, I wish I had a lightweight VCS on my system using which I would be able to make changes to my code during the commute and then push/grab them from my Linux systems.
I use git on my home system, but I can't really get it working on Windows. I don't want all that cygwin hack.
If it does not run natively on Windows, it just won't do.
What have you guys tried on your Windows system? Something that YOU use.
The big player at the moment seems to be Mercurial?
What would be best for a one (or maybe two) man team?
I just need to maintain :
Versioned copies of source code.
Checking in and out should be as less obtrusive as possible.
I am looking forward to a multiple Undo kind of feature (like that in an EMacs buffer) but persistent.
I really like the way git keeps track of lines moving between files in a source code set
I should be able to move part(s)/sub tree(s) of the source tree (each sub tree implies a module/plugin to my the main software I am building) to an archival system either completly or partially and restore them back from the archive as and when required and the system should track any changes to this tree as well.
I actually want to experiment with my code as much as possible without me manually keeping track of what I modified and what I need to undo once I try out some idea, so that I am back to where I want to continue from.
Notes : A similar topic came up a year ago : DVCS Choices - What's good for Windows?
I hope things have changed, and I really want people to share their own, real life experiences. Not something they recommend without using it or they think will work.
Bazaar and Mercurial both work very well on Windows. I posted in the question you linked, and since then, both have improved their Windows support even more. Using them is easy and flawless, and they even have GUIs if you swing that way.
I for one have switched from bazaar to git, and I've been pleased.
If you've a Clearcase background, why don't you take a look at Plastic SCM? Check this link, it will show you how it works on a distributed setup (and of course all the basic operations) http://codicesoftware.blogspot.com/2010/03/distributed-development-for-windows.html.
You won't miss any of the "good" clearcase features but all the shortcomings are simply gone (faster, installs on 45seconds, no cumbersome setup to use on a mixed Win/Linux scenario, built-in ACLs, excellent branching and merging, much better common ancestor algorithm, visualizations, better GUI, and you still have "selectors" in case you miss config_specs, but not being mandatory)
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
I'm looking for some help and it goes like this:
I'm a fairly green software developer, and focus mainly on the web (python/PHP) but am pretty well experienced with Java applications and as an electrical engineering student, looking forward to dive into some c/c++. I've pretty much grown up on Windows machine, but hate .net with a passion and dont really have a need to develop on Windows - besides the fact that i'm used to it.
I'm looking to switch to Ubuntu as my development machine entirely (without having WinXP on another partition) as I'm quite fedup with Windows, but am tempted to go back to it everytime i'm stuck with countless driver issues (be it headphone drivers, or dual monitor setup, etc). I'm looking for a comprehensive resource that will help this transition and doesn't assume you know alien linux shell keywords.
Cheers.
In my personal experience with Ubuntu, the two places that I consistently found help were Ubuntu Forums and Ubuntu Wiki. These two sites demonstrate just how helpful, organized, and motivated the Ubuntu Community is.
An additional resource is also the Ubuntu channel on IRC. Whenever I was stuck with an issue that I felt warranted a discussion with someone (or a handful of people), IRC was always a good place to go.
Lastly, I tend to learn a lot from reading blogs from people that are heavily involved in Ubuntu's development. Planet Ubuntu is a pretty good feed to keep in your reader. It's essentially an aggregation of a number of blogs. The majority of the posts are related to Ubuntu; however, there are occasional posts that are just about the developer's thoughts and opinions.
I would recommend you set up your PC in such a way that:
Have three partitions, one for swap (1-2x ram size), one for / (root dir) and one for /home.
Keep everything not related to running linux in /home, or on completely separate harddrives. Don't store stuff you wanna keep on the partition that holds /.
This allows you to rather effectively nuke your entire linux install and install another one without losing your data or your settings. This lets you do two things:
If you really break your install you can often just nuke it and reinstall. Most distros you're going to try will deal with upgrading you back to the current version quickly.
If you're not happy with, say, Ubuntu, you can just nuke it and install something else, say OpenSUSE, CentOS or Fedora.
The key thing to remember is that all your personal settings (desktop background, application settings etc) are stored in /home/yourname/ under hidden directories, definied by naming them with a '.', .gnome for example. System settings are stored in /etc, but with most distros these days system settings are so well guessed you never need to care. The data you care is under /home/yourname.
If you're going to move to another distro I would recommend copying those hidden directories into another directory under your home/yourname directory, say 'old-prefs' or something. This is because you want to start 'fresh' with the new install. You can copy back hidden dirs you know you want later (I for example would always copy back .opera, .mozilla).
Also, don't throw away your Windows install, not yet anyway. You may find Linux is not for you. You may find the inability to play any new games without rebooting a pain. You may find various things don't work as seemlessly as they do on Windows, in my experience that includes Adobe Flash and various sound-related things (sound has recently been rooted imo due to early PulseAudio adoption).
As other people have said, the Ubuntu wiki and Ubuntu forums are good, and for that reason it's the first distro I suggest you try. It's so popular that you often get better results in google by replacing 'linux' with 'ubuntu'.
Not an answer, per se, but some unsolicited advice:
All platforms have problems
Developing on one platform is pretty much like developing on another
Familiarity with both the *nix and Windows worlds is useful
Good luck!
I would agree with Tom's answer in terms of resources to answer questions. In addition to that, I would recommend being prepared to learn to use a command prompt and to learn a lot more about the underpinnings of the system than you are probably used to on Windows. Linux in general exposes the "machinery" of the OS quite a bit more frequently than Windows, and if you're the type of person that doesn't like to tinker with things occasionally then it is probably not for you.
For example, my dad is an engineer and experienced programmer, and he has no interest in using Linux, because he doesn't want to have to futz with things to get them working. For him, using Windows is all about the path of least resistance. I on the other hand, use OS X and Linux on a regular basis and I love that when things don't work, I at least have the option of digging in and fixing the problem. I love the ready availability of command line interfaces, multitude of scripting options, and the general openness Linux has. It's hard to tell from your post which type of personality you have, but if you're looking forward to digging into C/C++ and you enjoy electrical engineering, Linux will probably be a good fit for you.
Lastly, I highly recommend using the command prompt frequently, even when there are GUI interfaces. Linux GUI apps are frequently built on top of the console applications. It almost always will be easier to work with things if you're familiar with and comfortable with the command line. Most seasoned *nix users also find that eventually it becomes more efficient and comfortable to get many types of tasks done from a command prompt. If you plan to develop on Linux then this is all the more likely to occur as you get used to thinks like working with build tools and scripts that are common on UNIX platforms.
EDIT: One last thing I cannot recommend enough: use virtualization! Install something like VirtualBox, VirtualPC or VMWare Player to run Linux in a virtual environment. Virtualization has come along far enough since the days I started using Linux such that you can now install and run Linux in a full-screen environment almost indistinguishable from running it natively. Using a virtualized environemtn also will make things like drivers a non-issue, since the generic "hardware" should be supported out of the box. Virtualization or a "Live CD" version of Linux (such as the Ubuntu live CD) is a fantastic way to get used to Linux without having to throw out the safety blanket of Windows right away.
The other advice here is excellent. As somebody who made the same leap at the end of 2005, I just wanted to add my own two penneth.
Expect a steep learning curve. I'd been using Unix / Linux type servers for best part of 13 years when I switched. Not the same. When I switched is when I started learning. My productivity dipped at first, but I know SO much more about our deployment environment now - and of course productivity back an exceeded original. But it 'aint easy.
When you DO switch, you never look at an OS in the same way again. Makes it easy treating any OS as just a set of things you have to learn. This in itself is a good thing (tm)
The biggest problem at first is looking for linux equivalents of windows ways of doing things. I remember looking for decent FTP client (in the end IF I am forced to use FTP now, I use konqueror with two windows - but just wait till you discover rsync!), a decent graphical subversion client (then realised that knowing how to use find, sed, grep and svn cmd line client was much much better) etc.
I have heard people before say that resorting to the command line is admission of failure. While this may be true if there is no choice in it, you soon come to revel the blending of graphical and command line tools to get the job done. For example, I tend to use find and grep and xargs to load up my IDE with stuff I want to work on.
You learn to love computing again. The whole computer becomes a tool for getting things done.
The biggest change is the freedom. Not the cost. But that fact that installing software is as simple as "sudo apt-get install" or graphical equivalent. Even a very non-technical windows user soon comes to relish this amazing aspect that of Linux.
Enjoy!