This project is read-only.

WinMergeFS as service

Sep 15, 2009 at 11:02 PM

Hello! I'm so glad I found WinMergeFS. I've been looking for something like this for quite some time, and have really had no luck in free or paid software that I could find. Thank you so much for taking the time to make such an awesome app!

One problem I seem to be having, however, is understanding how to put WinMergeFS to use as a system service. I looked through the documentation, and saw the reference to installing the service, which I did. The service shows up, but every time I try to start it, I get a Services error saying that the service started and then stopped. It goes on to say that some services stop automatically when they have nothing to do...etc.

My original inkling was that the .exe being used as the service was lacking parameters, so I checked the service properties and used the -profile switch pointing to just the filename and then the full path and filename to no avail. Using the -manual switch featuring all the same info as contained in the .xml file results in the same Start/Stop error. I tested both methods from command line and both work fine, so I know it's not a matter of a typo.

I'm not a Windows internals expert by any means, and I'm sure it's a matter of something I just missed on my end, such as having to put the .xml profile in a specific directory or otherwise. I'd love to be able to have the persistent access to the merged directory without having to keep a user logged into this particular system (soon-to-be headless web/ftp server box) to keep it running. Any pointers on how to get me up and running would be greatly appreciated, and I'll keep plugging away, and if I figure it out myself, I'll post to let you know I'm good to go.

Again, thanks for a great software, and keep up the outstanding work!

Sep 16, 2009 at 1:11 PM

Dear helim,

thank you for using and testing WinMergeFS.
Please excuse the poor documentation.

To get WMFS to run as service, you need a special configfile. You can create a sample file with

WinMergeFS.exe -sample <filename>

where filename should be config.xml.

When WMFS starts as service it reads the config.xml and mounts the profiles specified in it. There are no extra parameters needed in the service properties.

I hope you will get it to run.

 

Best regards,
Duke

Sep 16, 2009 at 7:24 PM

Thanks for the tip, and the prompt response! I had wondered if the -sample switch might have had something to do with it, but had failed to put together the editing of the config to point to the existing .xml config file that I had been working with yesterday. I also created the sample config file with a name other than config.xml, which contributed to my confusion. I use an addon app called File Menu Tools to run apps with parameters, and by not running the file in a command shell, I missed the note about renaming to config.xml.

My short term solution was to use FireDaemon to set up the WnMergeFS executable as a system service, and point it to the config file I had originally created. That worked fine, but I'm glad to see that I won't have to purchase additional licenses for FD if I end up installing WinMergeFS on multiple systems!

Again, thanks for the help, and keep it up with this great app! You guys rock!

 

Sep 29, 2009 at 11:22 PM

I wanted to thank you for the tip re: running WinMergeFS as a service...I've had it up and running and have been very happy with it running as a service.

I've noticed a couple of issues that I want to bring to your attention, but first let me give you a little background on what I'm trying to do, so that what I'm asking might make a little more sense.

My primary reason for wanting to use WinMergeFS is to create what appears to my Web Server box (Win XP SP3 running Apache 2.2) to be a contiguous diskspace/directory for all of the files I want the server daemon to host, including static and dynamic content, as well as multimedia video and audio files. The main reasons for doing this are 1) to ease complications in configuring Apache to find all the content, and 2) so any of the files I may need or want to edit or deal with regarding the server are in one drive, thus reducing the need to deal with multiple directory trees on different computers.

I found that WinMergeFS is able to mount UNC (\\computer\path\to\files etc.) to the virtual directory, which I found very useful. Because I have media files on different computers in the network (one rig handles video editing, one used for office -related tasks, the web server box), it is nice to be able to use those paths and point to the different shares rather than having to put all the content on one actual drive.

Here's where I encounter my first problem. The WinMergeFS service is running on the server box, and creates the drive letter, and all is well. However, if for some reason I edit/move/delete a file that the WinMergeFS points to not in that created drive, but on the system that the config file points to, I can make the change on that local system, but WinMergeFS does not reflect the change unless/until I restart the service. I don't know if that's a limitation of WinMergeFS, the underlying Dokan Library, or if I have something misconfigured. Currently those UNC Paths are considered read-only by the config files.

My other question isn't so much of an issue for me, but am wondering if it's something that can be addressed. I noticed that if there is a root specified in the profile that is unavailable or invalid, WinMergeFS will fail to create the merged directory. Is it possible to have WinMergeFS ignore unavailable or invalid paths, and maybe pass error info to the log file to alert the user to check (in case of typo). The main reason for my concern re: this issue is that if one of my systems has been shutdown for whatever reason, and it happens to host one of the UNC Paths pointed to by the config profile, then WinMergeFS will fail to create a virtual drive, and the server daemon on that system doesn't have any content to point to.

Sheesh...okay I've rambled enough! Hope that all makes sense, and you can shed some light on what can be done to address the questions I've raised.

Again, thanks for the great software, and I look forward to hearing your reply! 

Sep 30, 2009 at 11:29 AM

Hi helim,

thank you very much again for testing and using WMFS.

I am a bit surprised that WMFS is able to mount UNC paths, since we didn't tried that before. But nice to know, thank you for that. :)

Both of your problems got the same source of error.
WMFS caches file and directory information to optimize access-speed. A FileSystemWatcher monitors the root paths for changes and clears the cache.
Apparenty this FSW does not work on UNC paths and it is the reason WMFS doesn't start when one of the roots is not available.

I plan to rewrite the cache and add a setting to disable the cache for each root, so make is possible to use a root path that might be unavailable some times (without the cache this works fine).

I hope I can finish this feature soon and provide a new release.

 

Best regards,

Duke

Oct 19, 2009 at 4:38 AM
Edited Oct 19, 2009 at 4:39 AM

Sorry for the long absence. Thanks again for your prompt response.

Glad to hear that I was able to (unintentionally) help re: the UNC paths...even though, as you pointed out in your previous post, that is where my refresh problems seem to stem from. I still believe that the positive gains far outweigh any negatives that arise, such as the FSW not working on UNC paths.

My workaround for this has been to create a scheduled task in Windows that basically stops and restarts the service (which your previous guidance helped me to configure beautifully) once a day. Under most circumstances, this restart has been sufficient, as changes do not occur too frequently on the UNC paths on their local ends, and there is little demand on the server, so if a file is pointed to, and it's not there (or at least WMFS doesn't cache it), it's not likely to be an issue that produces a 404 error. This setup is currently for development, and not production, so all users involved know me/can expect glitches or shortcomings along the way.

As the server box is now headless, if I DO make a change to something that will affect what WMFS sees on the server box, once my file operations are complete I can simply RDP to that box and manually stop/restart the service, and when it restarts, it sees the changes I've made (or seems to, in all the cases I've followed that procedure thus far).

For an extra bit of background on my setup, my network is currently in 'workgroup' configuration. Although I have a Windows Server 2003 box in the mix, the fact that at least two other systems are still running XP Home has precluded me from going to the 'domain' configuration. I don't know off the top of my head if this would have any bearing on the UNC path outcome (as it seems to work on 'workgroup', can it be assumed that it would work just the same in 'domain'?). One of these days I'll pony up and upgrade the installs of XP Home to something that will support Active Directory, and then maybe I can test out how UNC paths work out in that configuration.

Regardless, this software has been a godsend, and I sincerely thank you for it! Keep up the great work!