MAC OS version

[oskar101]

Love this program, have been using it almost daily on my windows device. Now
that I have an IMAC this is one of the programs I miss most. Any chance for a
MAC version ?

[Zenju]

> Any chance for a MAC version ?
Maybe there already is a MAC version? I do not have a MAC, so I cannot test
this. But in general it's quite possible, that one can simply compile and run
FreeFileSync on OS X: The GUI stuff is abstracted away by wxWidgets which
implements Cocoa, the rest of the OS dependent code is either Win32 or Posix.
Latter is supported by OS X.
A recipe for a FFS Mac version therefore might be:

1. compile wxWidgets for OS X
2. compile FreeFileSync as a Linux build

In practice there probably may be one problem or the other, but fundamentally
this should work.

[antsaoir]

Just moved most of my stuff to a IMAC, this is the one program I most miss, is there a MAC version yet ? An official apple app would be great and I am sure there would be a lot of customers on the MAC platform ...

[Zenju]

As far as I understand apple and GPL don't get along very well... especially for the app store.

[basovink]

I have been trying today to compile the FreeFileSync_5.10_source on OSX 10.7. After installing the packages mentioned in compile.txt using MacPorts I got stuck three times, of which I was able to the first 2:

• After trying *make* I got:
> cc1plus: error: unrecognized command line option "-std=gnu++0x"

This I fixed by installing gcc48. Apparently the version that comes with OSX (gcc42) doesn't know this command line option.

• Secondly the compile still didn't work with the same error. I figured out I needed to select the 4.8 compiler using
> port select gcc mp-gcc48

• Now it compiled until this error, which I am unable to fix:
>./zen/tick_count.h:117:9: error: '::clock_gettime' has not been declared

So, fellow OSX users, let's crack this nut! Who is able to take the next step?

[taofd]

It would be great if we could get this working natively on OSX!

Unfortunately, I don't have the skill-set to be able to contribute but, for those who would like an interim solution, there is a relatively easy work-around. You can run a linux distribution in a VM (i.e. virtual box), mount your target folder in your guest OS, mount your smb / cifs share and use freefilesync to keep everything synced. I mainly use ffs to sync files over my network, so depending on your goal, your miles may vary for the above.

Maybe takes 30 minutes to get everything set up (including VM installation). There aren't any good file sync alternatives on OSX that I've seen unless you're willing to use rsync which has no gui.

[antsaoir]

An OSX version / App would be great; I am surprised that there is not one yet.

[mrbogus27]

I am currently trying to create a working OSX version.
I already got rid of the errors in tick_count, but now i am stuck with icon_buffer.cpp .
In that class is a lot about getting rid of the refcounting done in wxwidgets, and this is done in a different way for each os. (@Zenju: i hope i got the right idea of what this class does? Maybe you can give me some help what and why exactly you do it that way? (gerne auch auf deutsch ;-)))

[fgirault]

Hi Matthias, I'm working on it too!
At the moment I just finished installing gcc48, but I think I'll continue tomorrow.
Keep posting your progress!

[mrbogus27]

Cool, in the attachment you'll find my changed version of zen/tick_count.h. I haven't tested it yet, but there are no more compiler error in that class. Do you have experiences in using wxwidgets?
Maybe Zenju can create a repository here and upload the sourcecode, and so we can work on it? Or would it be ok if i create a repository somewhere?

[fgirault]

Thanks, I'll check tonight.
Unfortunately I don't have experience with wxWidgets.
About the repository maybe it would be nice if we could use github.
But whatever is fine.
What do you say Zenju?

[mrbogus27]

That would also be my favorite for hosting, i also prefer git. What i forgot: you have to use the Linux CodeBlocks project, add the define FFS_MACOS to have my changes compiled.

[Zenju]

Thank you for your contribution, but currently I'm not looking for help with the source code. When considering what's needed for a Mac port, this is the least of the problems and is easier for me to do myself, else I'll have to review the new code to make sure it fits into the FFS coding style and adheres to the quality standards and functional correctness which will cost me more time in the end.

Instead what needs to be evaluated right now are general distribution topics:
- FFS requires gcc 4.7 or higher (or equivalent like clang). How to setup?
- Can wxWidgets be compiled with gcc 4.7/clang?
- wxWidgets 2.8.12 would be preferred since newer versions are partially buggy in use with FFS. Is this possible?
- Can wxWidgets practically be compiled in "universal binary" mode?
- Can boost be compiled with gcc 4.7/clang?
- Can the FFS make file construct be reused?

[fgirault]

That would also be my favorite for hosting, i also prefer git. What i forgot: you have to use the Linux CodeBlocks project, add the define FFS_MACOS to have my changes compiled.

Thx I just installed Code::Blocks (first time I use it). Still have some include path issues with wxWidgets.
I'll try with the wxWidgets-devel available from macport.

[fgirault]

Thx I just installed Code::Blocks (first time I use it). Still have some include path issues with wxWidgets.
I'll try with the wxWidgets-devel available from macport.

Ok now the I think all include path problems are solved (I just needed to add a link to wx folder in my /opt/local/include path) and using your file I got the attached errors in other parts of the code. I'll take a look later.

[fgirault]

Hi Zenju, just to answer some of your questions:

- FFS requires gcc 4.7 or higher (or equivalent like clang). How to setup?
It is easy to get gcc48 from macport:
http://www.macports.org/ports.php?by=name&substr=gcc48

- Can wxWidgets be compiled with gcc 4.7/clang?
We can get wxWidgets from macports too:
http://www.macports.org/ports.php?by=name&substr=wxWidget

- wxWidgets 2.8.12 would be preferred since newer versions are partially buggy in use
2.8.12 is available on macport

- Can wxWidgets practically be compiled in "universal binary" mode?
don't know

- Can boost be compiled with gcc 4.7/clang?
Boost is also available from macport
http://www.macports.org/ports.php?by=name&substr=boost

- Can the FFS make file construct be reused?
Well I don't really know, I just used code::block with your linux cbp file, and it seems to be almost working, except for few compile errors.

[mrbogus27]

Hi Zenju, thank you for your answer. Are you currently working on a mac port, or is it just something you plan to do in the future? On your questions: what Florian said is right, i can add something to the remaining questions:
* wxWidgets can be compiled in "universal binary" mode, the manual is here: http://wiki.wxwidgets.org/Development:_wxMac#Building_32.2F64_bit_Universal_Binary
* the makefile can be used, no problem. I added the define i mentioned to the compiler call, and had the same result as in CB.

[Zenju]

> Are you currently working on a mac port, or is it just something you plan to do in the future

The showstopper for me right now is that I have no working build environment on Mac. Since you two seem to have experience on Mac, maybe you can help me to set it up. Once the environment is running, the source code changes should be a piece of cake.

My Mac environment is x86_64 with OS X 10.8.2 and Xcode 4.6.

I've installed macports, but it didn't go too smooth:

- "sudo port install gcc48" failed with some error mentioning some "ld64"-related file already existing. I found as a workaround "sudo port clean --all all", then installing gcc48 again, followed with "sudo port select gcc mp-gcc48" did the trick. Also added "hash gcc" - no idea what that does, but gcc48 is selected and working now.

> We can get wxWidgets from macports too:

Very nice, I didn't know that. Compiling wxWidgets manually produces all kinds of crazy error: compiling fails with not finding "wcsncasecmp" even though, the configure-step before found it explicitly.
I'll test both boost and wxWidgets macport versions. If they work, then this would be a convenient solution. With regards to boost though I'll try to compile manually. FFS heavily relies on boost::thread, which is one of the boost components that get the most fixes with each release, so I'll try to be as current as possible. Unlike wxWidgets boost is updated frequently, so I expect this to work.

> Can the FFS make file construct be reused?

I'm wondering because as far as I understand the apple strategy, gcc will be superseeded by clang in the long run. But at least for now gcc48 can be used and this should work nicely with "make".

> wxWidgets can be compiled in "universal binary" mode, the manual is here

My question was not precise, what I wanted to ask was: Did you successfully compile wxWidgets as "universal binary" and if so, how? Following the wxWidgets instructions for manual compilation doesn't work for me and fails already at the "./configure" step. It seems architecture "ppc" is causing trouble, using only "i386 and x86_64" works, but "make" fails due to "wcsncasecmp" missing.

[fgirault]

Doest that answer your questions on universal binaries:
https://trac.macports.org/wiki/howto/buildUniversal

I didn't try it yet, but it looks promising.

[Zenju]

I've just finished a first sweep over the sources implementing most of the Mac-specific functionality. Thereby I've done a number of decisions that are a matter of convention, so let me know if any of the following needs to be adapted:

1. As "on completion" commands I've chosen:
Standby: osascript -e 'tell application "System Events" to sleep'
Log off: osascript tell application "System Events" to log out
Shut down: osascript tell application "System Events" to shut down

2. Default external applications:
Browse directory: open "%item_folder%"
Open with default application: open "%item_path%"
For Windows there's "explorer /select, "%item_path%"" to not only show the containing folder but also mark the selected file. Is there a similar command for OSX that could be used instead of "open "%item_path%""?

3. Default exclusion filter. I only found the following entry to be useful, are there more directories that should be included (for use with external hard disk)?
/.Trashes/

4. Case-insensitive file name comparison. Lacking official documentation from Apple I went with "::strncasecmp ::toupper" (both are locale-dependent!) until further to compare file names. What I am looking for is official developer documenation clearly stating what API to use for case-insensitive comparison. Windows for example has an MSDN article to clear ambiguity (at least for Vista upwards). FFS should model the behavior of the file system as closely as possible, so there probably exists a locale-independent comparison routine that should be chosen, but I couldn't yet find.

[mrbogus27]

1. Should be ok so.
2. there is the command open -R %item_path%. If there is already a open finder window, it does what it should, it shows the file in the finder. If there is no open finder window, it only opens the folder in the finder, but the file is not selected. Maybe there is a workaround for this?
3. I would also exclude .DS_Store, they are also mac-only.
4. that is really a typical problem when it comes to programming in non Objective-C for mac, there is not so much help from apple. I would try to find an answer at opensource.apple.com, maybe you find something there?

[Zenju]

> command open -R

Excellent, in my tests on OS X 10.8.2 it works exactly like ""explorer /select" even when the folder is not yet shown.

> programming in non Objective-C

There are two issues which commonly seem to be solved in Objective-C:
1. Recycle bin access
2. Finding associated file icons

I'm currently looking for a C-style solution, if nothing else helps I may need to make some aquaintance with Objective-C.

[fgirault]

i don't know if you're still wodering, but wxwidget 2.8.12 installs without problems as universal binaries with macport (i use macos 10.7.5)
else about filesystem related stuff, that should be possible using corefoundation
[404, Invalid URL: https://developer.apple.com/library/mac/documentation/CoreFoundation/Reference/CoreFoundation_Collection/_index.html]
I guess we need to wrap the features we want to use in some sort of static or dynamic library we can use with gcc48.
Unless Mathias has a better solution?

[Zenju]

OS X 10.8 deprecates Carbon and proposes Cocoa as an alternative. Consequently wxWidgets 2.8.12 which depends on Carbon fails to build on 10.8. Therefore I have to use wxWidgets 2.9.4 which uses Cocoa.

Generally it should be possible to statically link Objective C with C++. But I'm wondering:
Is it okay at this time to follow Apple's recommendation and use Cocoa?

E.g. the recycle bin API in Cocoa, trashItemAtURL:resultingItemURL:error:, requires Mac OS X 10.8 upwards. The older API, FSPathMoveObjectToTrashSync, is working since 10.5 but deprecated as of 10.8.

Are there any number on how many OS X users are on what version of the system? The statistics I found so far only showed the market share of all OS X versions combined.

[mrbogus27]

I would also use Cocoa, it is availiable since OS X 10.4, so every current mac should have it. Relating to this i found http://stackoverflow.com/questions/525609/use-c-with-cocoa-instead-of-objective-c
The recycle bin API seems to have changed in 10.8, i would detect the OS version and then call the appropriate function. Detecting the OS X version is explained here: http://stackoverflow.com/questions/5969485/getting-the-os-version-in-mac-os-x-using-standard-c , there is also a discussion why to do it that way: http://www.cocoabuilder.com/archive/cocoa/222660-how-do-you-get-the-os-version-number-in-or.html
Related to the issue with open -R, i have installed the XtraFinder-Addition, maybe this breaks the command. I need to check it when i am back at my mac.

[Zenju]

I've found the following statistics about OS X version distribution:
http://www.atomicbird.com/sparkle-stats
[404, Invalid URL: http://hints.macworld.com/polls/index.php?pid=snowingyet]
[404, Invalid URL: http://hints.macworld.com/polls/index.php?pid=20100310053852122]

So it seems like supporting 10.5 upwards will be sufficient.

> Detecting the OS X version is explained here:

Thanks!

> detect the OS version and then call the appropriate function

This leads to a general question: For Linux FFS does not try to create universal executables, but requires that it is compiled for each distribution separately.
Windows on the other hand has an excellent "backwards compatibility story" that allows FFS to support all versions since Windows 2000 with a single executable.
What about Mac: Is it possible to support 10.5 upwards with a single executable or do we need separate compilation?
I'm not too far away from finishing the RealtimeSync application bundle, but am not sure if it will work on other OS X than 10.8.2.

[fgirault]

http://forums.macrumors.com/showthread.php?t=1187953

It seems possible to check availability of api functions at runtime. That'd allow to have a single binary.

ps: there's a link to apple documentation

[Zenju]

I've finished compiling and running Realtimesync with gcc4.8, but without the monitoring component for now. The next step is to package and release it as an app. The most urgent question so far is:

How to distribute dynamic libraries in an application bundle?

I could link both wxWidgets and boost statically or dynamically, but am unsure about what is better. There are other dynamic libraries where there is less choice, e.g. libstd++. It seems one should package dynamic libraries in a subdirectory of the app package.
There is a tool "install_name_tool" which can change the path of the dependent dynamic libs of an executable. But doing this manually is excruciatingly tedious and error prone.

What is the standard solution to this? Is it to use Xcode to have the app bundle created automatically? I have yet to find a way to setup a wxWidgets app to compile and run with Xcode 4.6. The requirements are demanding:
- have a universal build with at least i386, 64
- gcc4.8 (maybe clang will work with FFS???)
In Xcode 4.6 I cannot even find "Other C Flags" anymore to put wxWidget header files. Proper support for C++ looks different...

[mrbogus27]

Dynamic linking seems to be fine, you can add the necessary libs to the .app bundle. There is a good guide from Apple how to build bundles: https://developer.apple.com/library/mac/#documentation/CoreFOundation/Conceptual/CFBundles/AboutBundles/AboutBundles.html The relevant part about .app bundles is this one: https://developer.apple.com/library/mac/#documentation/CoreFOundation/Conceptual/CFBundles/BundleTypes/BundleTypes.html#//apple_ref/doc/uid/10000123i-CH101-SW13

Regarding the question of dynamic vs static, i found this discussion: [404, Invalid URL: http://cocoadev.com/wiki/ApplicationLinking]

The result is: it can be done without Xcode, a bundle is just a directory with a special organization.

[Zenju]

Okay, after evaluating all the options, I found the ideal solution that doesn't require any non-standard packages that users might now have: Use LLVM Clang + static linking of wxWidgets and boost.

The port of both RealtimeSync and FreeFileSync is not at all complete, but I just finished a first package. So for an initial test, I'd like to know if you are able to start both tools at all. I've compiled with the 10.7 SDK, the oldest SDK available on Mountain Lion, so OS X 10.7 should work, but I'm not sure if it works on 10.6.

[404, Invalid URL: http://freefilesync.sourceforge.net/FreeFileSync_5.13_OSX_10.7_64bit.zip]