spartanj / efsw Goto Github PK

Original report by Petr Vanek (Bitbucket: pvanek, GitHub: pvanek).

hi Martin,
I'm trying to push code based on your work into the official suse/fedora distro. I just found that files in your hg repository with those (minor) warnings:

1. Mutex.* and Thread.* are stored with executable privileges in the main hg repository. It should be rw-r--r-- to silence warnings

2. is it really required to use "inotify-nosys.h" directly? It seems to me like a system header duplication. I don't know premake at all, it's easy to resolve in cake...

anyway, thanks for great library you made

Original report by Anonymous.

Makefile

#!makefile

CC=g++
CFLAGS=-I/Users/ritesh/Programming_stuffs/cpp/SpartanJ-efsw-e533340d8dcc/include
EXEC=main
LIBS=/Users/ritesh/Programming_stuffs/cpp/SpartanJ-efsw-e533340d8dcc/lib/libefsw-static-debug.a
INCDIR=

all: $(EXEC)
	
debug: CFLAGS+=-g -DDEBUG
debug: clean $(EXEC)
	
main: main.cpp
	$(CC)  $(CFLAGS) $(INCDIR) -o main main.cpp $(LIBS)




.PHONY: clean
clean:
	rm -rf $(EXEC) *.dSYM

Using

#!c++

efsw::FileWatcher * fileWatcher = new efsw::FileWatcher();

gives following

Undefined symbols for architecture x86_64:
"_CFArrayCreate", referenced from:
efsw::WatcherFSEvents::init() in libefsw-static-debug.a(WatcherFSEvents.o)
"_CFBundleCopyBundleURL", referenced from:
efsw::Platform::System::getProcessPath() in libefsw-static-debug.a(SystemImpl.o)
"_CFBundleGetMainBundle", referenced from:
efsw::Platform::System::getProcessPath() in libefsw-static-debug.a(SystemImpl.o)
"_CFRelease", referenced from:
efsw::FileSystem::precomposeFileName(std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > const&) in libefsw-static-debug.a(FileSystem.o)
efsw::WatcherFSEvents::init() in libefsw-static-debug.a(WatcherFSEvents.o)
"_CFRunLoopGetCurrent", referenced from:
efsw::FileWatcherFSEvents::run() in libefsw-static-debug.a(FileWatcherFSEvents.o)
"_CFRunLoopRunInMode", referenced from:
efsw::FileWatcherFSEvents::run() in libefsw-static-debug.a(FileWatcherFSEvents.o)
"_CFRunLoopStop", referenced from:
efsw::FileWatcherFSEvents::~FileWatcherFSEvents() in libefsw-static-debug.a(FileWatcherFSEvents.o)
"_CFStringCreateMutableCopy", referenced from:
efsw::FileSystem::precomposeFileName(std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > const&) in libefsw-static-debug.a(FileSystem.o)
"_CFStringCreateWithCString", referenced from:
efsw::FileSystem::precomposeFileName(std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > const&) in libefsw-static-debug.a(FileSystem.o)
efsw::WatcherFSEvents::init() in libefsw-static-debug.a(WatcherFSEvents.o)
"_CFStringGetCString", referenced from:
efsw::FileSystem::precomposeFileName(std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > const&) in libefsw-static-debug.a(FileSystem.o)
"_CFStringNormalize", referenced from:
efsw::FileSystem::precomposeFileName(std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > const&) in libefsw-static-debug.a(FileSystem.o)
"_CFURLGetFileSystemRepresentation", referenced from:
efsw::Platform::System::getProcessPath() in libefsw-static-debug.a(SystemImpl.o)
"_FSEventStreamCreate", referenced from:
efsw::WatcherFSEvents::init() in libefsw-static-debug.a(WatcherFSEvents.o)
"_FSEventStreamInvalidate", referenced from:
efsw::WatcherFSEvents::~WatcherFSEvents() in libefsw-static-debug.a(WatcherFSEvents.o)
"_FSEventStreamRelease", referenced from:
efsw::WatcherFSEvents::~WatcherFSEvents() in libefsw-static-debug.a(WatcherFSEvents.o)
"_FSEventStreamScheduleWithRunLoop", referenced from:
efsw::WatcherFSEvents::initAsync() in libefsw-static-debug.a(WatcherFSEvents.o)
"_FSEventStreamStart", referenced from:
efsw::WatcherFSEvents::initAsync() in libefsw-static-debug.a(WatcherFSEvents.o)
"_FSEventStreamStop", referenced from:
efsw::WatcherFSEvents::~WatcherFSEvents() in libefsw-static-debug.a(WatcherFSEvents.o)
"_kCFAllocatorDefault", referenced from:
efsw::FileSystem::precomposeFileName(std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > const&) in libefsw-static-debug.a(FileSystem.o)
efsw::WatcherFSEvents::init() in libefsw-static-debug.a(WatcherFSEvents.o)
"_kCFRunLoopDefaultMode", referenced from:
efsw::FileWatcherFSEvents::run() in libefsw-static-debug.a(FileWatcherFSEvents.o)
efsw::WatcherFSEvents::initAsync() in libefsw-static-debug.a(WatcherFSEvents.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Original report by Ugo Robain (Bitbucket: wizzhard, GitHub: wizzhard).

Hello,

After some tests it seems that Moved event only occurs when a file is renamed. When a file is actually moved we get a couple of event Delete, Add.

May be the Moved event could be renamed Renamed.

Original report by Mihail Slobodyanuk (Bitbucket: mihail_slobodyanuk, ).

If we try to establish watch on '/' path then we got efsw::Errors::FileNotFound error code
It's caused by two code points:

1. FileInfo::getInfo() remove trailing '/' in file path then call stat on empty path. Error result of stat should be properly handled.
2. FileSystem::dirRemoveSlashAtEnd() should not remove single '/' in path

Also if remove/add trailing slash have sence only mingw32 maybe better to do it only in case compiling for WIN32.

Original report by Karol Woźniak (Bitbucket: KenjiTakahashi, GitHub: KenjiTakahashi).

It apparently works fine somehow with default toolkit (gcc 4.2), but fails with custom ones (like 4.8).

Quite easy to fix: Just swap lines 10 and 11 in WatcherKqueue.hpp, so types get includes before event.

Original report by Anonymous.

Propose to include inotify.h to distro.
Rationale: many NAS devices used very old libc version without Inotify support.
But kernel it's.

I take all definitions from https://github.com/azatoth/minidlna/blob/master/linux/inotify-syscalls.h
Also it compatible with C++98

If you put attached file into include/sys when it will be found after unsuccessful search in system includes

Original report by Petr Vanek (Bitbucket: pvanek, GitHub: pvanek).

I'd suggest to add new "make" target to build the library with debugging symbols but with NDEBUG define and with "release" name.

Why? For packaging. There are various policies in Linux distributions for packages. Most of them are handled somehow like this:

• libefsw - containing the raw, strip'ed library, ideally with so name (libefsw.so.0…)
• libefsw-devel - containing header files, static lib, *.so symlinks...
• libefsw-debug - debugging symbols stripped from main library

The code below is quick hack how to do it. Unfortunately I'm really newbie in premake4 so I almost don't know what I'm doing ;)

Also there is no so name support for in the patch as I don't know how to do it in premake…

Ideally the result should be like:

#!

lrwxrwxrwx 1 root root       17 Dec 17 10:40 libefsw.so -> libefsw.so.0.0.1
lrwxrwxrwx 1 root root       17 Dec 17 10:40 libefsw.so.0 -> libefsw.so.0.0.1                                                    
-rwxr-xr-x 1 root root 15031644 Dec 17 10:40 libefsw.so.0.0.1 

#!diff

pvanek@linux-mq4l:~/oss/fsevent/efsw> hg diff
diff -r 56e08b85c928 premake4.lua
--- a/premake4.lua      Tue Dec 17 01:40:58 2013 -0300
+++ b/premake4.lua      Tue Dec 17 11:14:37 2013 +0100
@@ -52,7 +52,7 @@
 solution "efsw"
        location("./make/" .. os.get() .. "/")
        targetdir("./bin")
-       configurations { "debug", "release" }
+       configurations { "debug", "release", "relwithdebinfo" }
 
        if os.is("windows") then
                osfiles = "src/efsw/platform/win/*.cpp"
@@ -104,6 +104,12 @@
                        flags { "Optimize" }
                        targetname "efsw-static-release"
                        conf_warnings()
+
+               configuration "relwithdebinfo"
+                       defines { "NDEBUG" }
+                       flags { "Symbols" }
+                       targetname "efsw-static-relwithdebinfo"
+                       conf_warnings()
 
        project "efsw-test"
                kind "ConsoleApp"
@@ -125,6 +131,13 @@
                        targetname "efsw-test-release"
                        conf_warnings()
 
+                configuration "relwithdebinfo"
+                        defines { "NDEBUG" }
+                        flags { "Symbols" }
+                        targetname "efsw-test-relwithdebinfo"
+                        conf_warnings()
+
+
        project "efsw-shared-lib"
                kind "SharedLib"
                language "C++"
@@ -146,3 +159,10 @@
                        flags { "Optimize" }
                        targetname "efsw"
                        conf_warnings()
+
+                configuration "relwithdebinfo"
+                        defines { "NDEBUG" }
+                        flags { "Symbols" }
+                        targetname "efsw"
+                        conf_warnings()
+

Original report by Kevin Jurkowski (Bitbucket: Driklyn, GitHub: Driklyn).

If you rename a file that's 12 or more characters long (not including the extension), it causes the program to freeze.

For instance, renaming redrectangle.png to redrectangle2.png causes a freeze. Renaming it to a shorter length, such as redrect.png, also causes a freeze.

Adding/deleting/moving does not.

Windows 7 x64

Original report by Greg Lee (Bitbucket: glee_hokie, ).

efsw reports EOVERFLOW when a directory on a CIFS/samba mount is specified as a monitor point. The reason is that CIFS mounts require a larger return structure for the stat() function. The solution is to #define _FILE_OFFSET_BITS 64 in the two files that call stat() - FileInfo.cpp and platform/posix/FileSystemImpl.cpp.

Here's a link that should fill you in on this (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604928).

FYI, you must use the generic monitor with CIFS mounts since they do not support the inotify API.

Original report by Sepehr Taghdisian (Bitbucket: sepul, GitHub: sepul).

destroying efsw object lead to system exception on windows impl:
I did a hack to get mine working , check it out here :
https://bitbucket.org/sepul/efsw/commits/95e5c36765b8a25d2ade4dc36e150c51b4021b21#chg-src/efsw/FileWatcherWin32.cpp

If I delete that branch, the program will fail with exception upon exit, because mHandles array is empty when calling WaitForMultipleObjectsEx

Original report by Mihail Slobodyanuk (Bitbucket: mihail_slobodyanuk, ).

Test code attached (main.cpp).
Only for Linux implemented asynchronous watch thread finalizing. If watcher not waiting in read(), then SIGABRT or SIGSEGV raised.
I made a several experiments with deferred and immediate thread cancellation but have no good results. In finally i rewrite code to synchronous interrupt. I used select() with timeout to check is events present and avoid blocking on read(). See FileWatcherInotify.diff

Original report by Sarvagya Pant (Bitbucket: sarvpant, ).

I am trying to use efsw for monitor the filesystem of my computer. I have prepared following code:

#!c++
class UpdateListener : public efsw::FileWatchListener
{
public:
    UpdateListener() {}

    void handleFileAction( efsw::WatchID watchid, const std::string& dir, const std::string& filename, efsw::Action action, std::string oldFilename = "" )
    {
        switch( action )
        {
        case efsw::Actions::Add:
            std::cout << "DIR (" << dir << ") FILE (" << filename << ") has event Added" << std::endl;
            break;
        case efsw::Actions::Delete:
            std::cout << "DIR (" << dir << ") FILE (" << filename << ") has event Delete" << std::endl;
            break;
        case efsw::Actions::Modified:
            std::cout << "DIR (" << dir << ") FILE (" << filename << ") has event Modified" << std::endl;
            break;
        case efsw::Actions::Moved:
                std::cout << "DIR (" << dir << ") FILE (" << filename << ") has event Moved from (" << oldFilename << ")" << std::endl;
            break;
        default:
            std::cout << "Should never happen!" << std::endl;
        }
    }
};


int main()
{
	efsw::FileWatcher *fileWatcher = new efsw::FileWatcher();
	UpdateListener *listener = new UpdateListener();
	efsw::WatchID id1 = fileWatcher->addWatch("C://SomeFolder",listener,1);
        fileWatcher->watch();
	while(1)
	{
		efsw::System::sleep(10000);		
	}
	
}

I am monitoring the folder C:/SomeFolder. Inside this folder there is a log writer that write to file output.log. Currently efsw is unable to watch this file even though it is in the monitored folder and is being modified continuously. But when I open this file, the efsw triggers notification. Is this an issue or am I doing something wrong?

Original report by Batte HUCHAI (Bitbucket: bhuchai, ).

Hello,

I have some troubles with EFSW on Mac OS v10.7.5. Events seem to be sent with a shift ...

For example :

I have 2 files in my watched folder : BAR.txt and FOO.txt

1. I delete BAR.txt : no event is sent.

2. I rename FOO.txt in FOO2.TXT : the below event will be printed :

DIR (/Users/myuser/Documents/) FILE (FOO.txt) has event Moved from (BAR.txt)

3. I create TEST.txt : the below event will be printed :

DIR (/Users/myuser/Documents/) FILE (TEST.txt) has event Added

4. I rename TEST.txt in TEST2.txt : the below event will be printed :

DIR (/Users/myuser/Documents/) FILE (FOO2.txt) has event Moved from (TEST.txt)

So, the only correct step is the number 3. All others seem to be shifted compared to normal way.

It's important to know that if I do the same 3 steps directly by command lines (Terminal), no from Finder, it's working. Is problem coming from Finder ?

Do you have any idea ?

Thanks by advance,

B.

Original report by Roland Rosenkranz (Bitbucket: Glatzemann, GitHub: Glatzemann).

System: Windows 8.1
Compiler: Visual Studio 2012

Steps to reproduce:

• use sample code from readme
• start program watching a directory containing a text file
• open the textfile and make some changes
• save the textfile

No event is triggered. When creating a new file and modifying it after creation, everything works as expected.

Original report by Yash pal (Bitbucket: codeyash, GitHub: codeyash).

FileSystemWatcher\src\efsw\WatcherWin32.cpp line no 32

I've to add LPSTR
to below section

		int count = WideCharToMultiByte(CP_UTF8, 0, pNotify->FileName,
			pNotify->FileNameLength / sizeof(WCHAR),
            (LPSTR)szFile, MAX_PATH - 1, NULL, NULL);
		szFile[count] = TEXT('\0');

        std::string nfile( (LPSTR)szFile );

If possible please detect mingw and add this.

Original report by takuya kikuchi (Bitbucket: t_kikuchi_skeed, ).

efsw crashes when i execute many file operations(file creation, renaming, and directory creation, repeat each operations about 100 times) in a short time on OS X 10.8.5.

In my fork, I fixed it and improve processing which associates filename and old filename in rename operations.

https://bitbucket.org/t_kikuchi_skeed/efsw/commits/765769a4f2304aba7652f1e9ddf5ac9ef8759be0?at=default#chg-src/efsw/WatcherFSEvents.cpp

Sorry my English is limited.

Original report by Dominic Oram (Bitbucket: D_Oram, ).

I have found a problem running efsw under Windows.

A watch can be adding from a thread other than the one in which the FileWatcher was first created. When the directories method is called on the FileWatcher this watch is included. However, the listener is not called when any file event occurs in the watch.

Not a large issue as I just made sure all watches were added on the same thread but is something that future users might need to be aware of.

Original report by Guillaume BOTTESI (Bitbucket: gbottesi, GitHub: gbottesi).

Hi!

Sometimes, depending on hardware, I have a crash when deleting an instance of FileWatcher.
It seems to happen if I have overlapped operations during DestroyWatch method.

I fixed it by replacing CancelIO by CancelIOEx in DestroyWatch (and, bonus, I could then remove the 5ms sleep.)

Here is how it looks like :

	tWatch->StopNow = true;
	CancelIoEx(tWatch->DirHandle, &pWatch->Overlapped);
	RefreshWatch(pWatch);
	CloseHandle(pWatch->Overlapped.hEvent);
	CloseHandle(pWatch->Watch->DirHandle);
	efSAFE_DELETE_ARRAY(pWatch->Watch->DirName);
	efSAFE_DELETE( pWatch->Watch );
	HeapFree(GetProcessHeap(), 0, pWatch);

This is quite a random bug and I don't really have a way to reproduce (well other than my complete soft here which I can't really give you).

Reading MSDN :
https://msdn.microsoft.com/en-us/library/windows/desktop/aa365683%28v=vs.85%29.aspx

It's said :

CancelIo—this function only cancels operations issued by the calling thread for the specified file handle.
CancelIoEx—this function cancels all operations issued by the threads for the specified file handle.

I think we may have operation from different threads in your lib...

Original report by Nils Desle (Bitbucket: nilsdesle, ).

When you add a folder to watch, it calls FileInfo::exists at some point. This method does not have the fix to remove trailing slashes before calling _wstat, which the other methods in FileInfo do, so _wstat returns -1 even if the folder exists.

Original report by Mihail Slobodyanuk (Bitbucket: mihail_slobodyanuk, ).

I attaching patch to fix many warnings about value greater or less variable's max/min value then comparison

Original report by Yash pal (Bitbucket: codeyash, GitHub: codeyash).

AddWatch we can add dir only... No Files?

If yes that is really a big problem. I need to monitor files for all kind of modifications.

Please comment.

Original report by Yash pal (Bitbucket: codeyash, GitHub: codeyash).

Is there any function which supports adding files or folders in ignore list.

Like in a folder we want to leave particular folder by adding in ignore list.

Practically like .DS_Store should not be reported for modification or if we can add in ignore list.
DIR ( "/Users/yashpal/Documents/Projects/www/ivertis/" ) FILE ( ".DS_Store" ) has event Modified

Original report by Sepehr Taghdisian (Bitbucket: sepul, GitHub: sepul).

In my initial version I added #ifdef __cplusplus to the efsw.h header. But it seems that it was removed in your version.
This leads to invalid export symbol names in the static library.
please add the following lines to the start and end of the C-API functions declarations:
https://bitbucket.org/sepul/efsw/commits/95e5c36765b8a25d2ade4dc36e150c51b4021b21#chg-include/efsw/efsw.h

Another suggestion is that please let void* param; remain in the C-API functions (when registering callbacks), it is extremely useful in C apis when we want to register an event or callback, and used pretty much everywhere in other C APIs.
For example check out pthread_create or CreateThread documentation.

Original report by Yash pal (Bitbucket: codeyash, GitHub: codeyash).

Qt Creator IDE
Windows 8.1
Qt 5.2.1

Part 1

DIR = "N:/Projects/www/vertis" FILE = "buttons" has event Delete
DIR = "N:/Projects/www/vertis" FILE = "buttons" has event Delete

Added a folder recursively for watching. deleted one of inside folder(contains one file only)

I don't know if it is bug or correct but it looks like a BUG to me.

Part 2 SOLVED:

DIR = "N:/Projects/www/vertis"
FILE = "contact.htmll??k�?(" has event Moved from "contact1.html??k�?("

DIR = "N:/Projects/www/vertis"
FILE = "contact.htmll" has event Moved from "contact1.html??k�?("

Also why so weird chars.

Using below code
qDebug() << "DIR =" << QString::fromStdString(dir) << "\n FILE ="
<< (QString::fromStdString(filename)) << ") has event Added\n\n" ;

Part 3 SOLVED

DIR = "N:/Projects/www/vertis" FILE = new-shik.png� has event Added

DIR = "N:/Projects/www/vertis" FILE = "new-shik.png" has event Modified

DIR = "N:/Projects/www/vertis" FILE = "new-shik.png�" has event Modified

DIR = "N:/Projects/www/vertis" FILE = "new-shik.png" has event Modified

DIR = "N:/Projects/www/vertis" FILE = "new-shik.png�" has event Modified

If file is being copying it should wait untill before saying added or modified. So many modified seems not ok. And again filename contains extra chars. WHY. Am I doing something wrong.

Original report by Ugo Robain (Bitbucket: wizzhard, GitHub: wizzhard).

Hello,

I met some issue with vs2010 here is a summary of what i have found

"premake vs2010" produce a project that contains gcc build options which prevent it from successfully compiling

buildoptions{ "-Wall -pedantic -Wno-long-long" } should be guarded with code detecting if gcc the target compiler

A lot of warnings are produced

add define _SCL_SECURE_NO_WARNINGS under windows

line 101 of efsw.h produce a fatal error because of EFSW_API placement.

replace

const char * EFSW_API efsw_getlasterror();

with

EFSW_API const char * efsw_getlasterror();

**Some linkage warning are produced because some files are empty under windows **

remove these files from project under windows

• WatcherKqueue
• WatcherFSEvents
• FileWatcherKqueue
• FileWatcherInotify
• FileWatcherFSEvents

Output file name are not "standard"

In order to avoid manual displacement of output file, they should be either placed in 2 different directories with the same name ex:

Lib/Debug/efsw_static.lib

Lib/Release/efsw_static.lib

either placed in the same directory the debug lib postfixed with d letter.

Lib/efsw_staticd.lib

Lib/efsw_static.lib

I hope all of this will help, nice work ;)

Original report by Yash pal (Bitbucket: codeyash, GitHub: codeyash).

I'm renaming file. I'm getting

#!log


DIR ( "/home/yash/Projects/qt/KiWi/kiwi-doc/" ) FILE ( "ApiEvents.textile1" ) has event Moved from ( "ApiEvents.textile" )
Reload PATH: "/home/yash/Projects/qt/KiWi/kiwi-doc"
DIR ( "/home/yash/Projects/qt/KiWi/kiwi-doc/" ) FILE ( "ApiEvents.textile1" ) has event Delete
Reload PATH: "/home/yash/Projects/qt/KiWi/kiwi-doc"
DIR ( "/home/yash/Projects/qt/KiWi/kiwi-doc/" ) FILE ( "ApiEvents.textile" ) has event Added
Reload PATH: "/home/yash/Projects/qt/KiWi/kiwi-doc"
DIR ( "/home/yash/Projects/qt/KiWi/kiwi-doc/" ) FILE ( "ApiEvents.textile" ) has event Modified

Sometimes proper Moved event and sometimes Deleted, Added series of events.

Am I doing anything wrong or its just OS specific. I want proper Moved event in all renaming cases and not deleted,added... series.

I don't know its bug or just random behavior or correct behavior.

Original report by Ugo Robain (Bitbucket: wizzhard, GitHub: wizzhard).

It seems that events are sent twice sometime. This is valid for all events (add, delete, moved, modified)

I use windows 7 x64 with a not generic file watcher.

Original report by Mihail Slobodyanuk (Bitbucket: mihail_slobodyanuk, ).

Hi, Martin!

I run into issue on Windows with generic backend.
Steps to reproduce:

1. Establish watch to some folder e.g. c:\efsw\1
2. Create in c:\efsw\1 new file.
3. Delete c:\efsw\1 folder.
   Expected result: one delete for c:\efsw\1\file
   Actual result: infinity events loop about delete c:\efsw\1\file

Thanks!

Original report by Anonymous.

I got this error
../../src/efsw/platform/posix/SystemImpl.cpp:91: error: 'PATH_MAX' was not declared in this scope

As i understand in some reason <linux/limits.h> which have PATH_MAX don't imported on a some toolchains but present in its.

To resolve i simply replaced POSIX define PATH_MAX to C++ define FILENAME_MAX.
Patch attached.

Original report by Nils Desle (Bitbucket: nilsdesle, ).

Reproduce scenario:
Run the test app on an empty folder
Copy several folders (5 in my case) full of pictures, with a total of over 1000 files to this folder
Delete 2 of the folders
Create a new file in the root of the watched folder

Observe that the last change (file creation) is not reported, and no subsequent changes are reported either. Nothing is reported anymore and quitting the app is the only thing you can do.

This is using the normal Win32 watcher, so not the generic one, on Windows 7

Original report by Sepehr Taghdisian (Bitbucket: sepul, GitHub: sepul).

Hi Martin
The destructor (FileWatcherWin32) attempts to operate on a mThread pointer, were it can be NULL sometimes (like when you don't watch anything before you exit), so it will generate access violation.

I have fixed it in my fork of efsw, though you may want to check it out :
https://bitbucket.org/sepul/efsw/commits/ca34370fd2806afa1fdb8a1f134fee912a5d7992#chg-src/efsw/FileWatcherWin32.cpp

(Also in the fork, I have added vs2012 project files, you may like to add them to your own project, but notice that they use EFSW_NO_WIDECHAR flag , cuz I don't use wide chars)

Original report by Karol Woźniak (Bitbucket: KenjiTakahashi, GitHub: KenjiTakahashi).

Like the title says: I think it should fire something, preferably a Delete action (because from our view, that file is gone), but no action at all is not good.

For example: We watch directory D with file F. From inside D, we do mv F ../. The file is gone, yet there's no action.

It was observed on Linux, I have no way to test other OSes ATM.

Original report by Petr Vanek (Bitbucket: pvanek, GitHub: pvanek).

current master branch. I got a lookup error when I tried to get directories list:

undefined symbol: _ZN4efsw11FileWatcher11directoriesEv

current quick fix resolved it for me:

#!diff


pvanek@stimpy:~/oss/fsevents/efsw/src/efsw> hg diff
diff -r d91c3d60171e src/efsw/FileWatcher.cpp
--- a/src/efsw/FileWatcher.cpp  Wed Nov 27 22:43:35 2013 -0300
+++ b/src/efsw/FileWatcher.cpp  Mon Dec 16 15:59:52 2013 +0100
@@ -102,6 +102,11 @@
        mImpl->watch();
 }
 
+std::list<std::string> FileWatcher::directories()
+{
+       return mImpl->directories();
+}
+
 void FileWatcher::followSymlinks( bool follow )
 {
        mFollowSymlinks = follow;

Original report by Petr Vanek (Bitbucket: pvanek, GitHub: pvanek).

at first - I'm not sure if I use the library correctly...
The problem is described in main() function.

#!c++
// g++ -I"/export/home/pvanek/oss/fsevents/efsw/include/" -L "/export/home/pvanek/oss/fsevents/efsw/lib/" -l efsw-debug main.cpp
#include <efsw/efsw.hpp>
#include <iostream>
// sleep
#include <unistd.h>

using namespace efsw;

class FSWatcherPriv : public FileWatchListener {
protected:
     virtual ~FSWatcherPriv();

public:
     FSWatcherPriv();

     int addWatch(const char * path, bool recursive);
     void removeWatch(WatchID id);
     void removeWatch(const char *path);

     void handleFileAction(WatchID watchid, const std::string& dir, const std::string& filename, Action action, std::string oldFilename = "");

private:
    FileWatcher *m_fw;
};

FSWatcherPriv::FSWatcherPriv() {
    m_fw = new FileWatcher();
    m_fw->watch();
}

FSWatcherPriv::~FSWatcherPriv() {
    delete m_fw;
}

int FSWatcherPriv::addWatch(const char * path, bool recursive) {
     WatchID id = m_fw->addWatch(path, this, recursive);
     return id;
}

void FSWatcherPriv::removeWatch(WatchID id) {
    m_fw->removeWatch(id);
}

void FSWatcherPriv::removeWatch(const char * path) {
    m_fw->removeWatch(path);
}


void FSWatcherPriv::handleFileAction(WatchID watchid, const std::string& dir, const std::string& filename, Action action, std::string oldFilename) {
    std::cout << " FSWatcherPriv::handleFileAction " << dir << " " << filename << " " << action << " " << oldFilename <<  std::endl;
}


int main(int argc, char **argv)
{
     FSWatcherPriv *f = new FSWatcherPriv();
     int id = f->addWatch("/export/home/pvanek/src/qore/module-fsevent/build/", true);
     std::cout << "added id " << id << std::endl;

     sleep(5); // here I try to "touch t.q", events are generated

     f->removeWatch(id);
     id = f->addWatch("/export/home/pvanek/src/qore/module-fsevent/build/", true);
     std::cout << "re-added id " << id << std::endl;

     sleep(5); // here the "touch t.q" runs again with no events at all

     return 0;
}

the stdout looks:

#!sh

pvanek@stimpy:~/src/qore/module-fsevent/trunk/src/err> ./a.out 
added id 1
 FSWatcherPriv::handleFileAction /export/home/pvanek/src/qore/module-fsevent/build/ t.q 3 
re-added id 13
pvanek@stimpy:~/src/qore/module-fsevent/trunk/src/err> 

all works fine when I use addWatch(..., false); flag:

#!sh

pvanek@stimpy:~/src/qore/module-fsevent/trunk/src/err> ./a.out 
added id 1
 FSWatcherPriv::handleFileAction /export/home/pvanek/src/qore/module-fsevent/build/ t.q 3 
re-added id 2
 FSWatcherPriv::handleFileAction /export/home/pvanek/src/qore/module-fsevent/build/ t.q 3 
pvanek@stimpy:~/src/qore/module-fsevent/trunk/src/err>

Is it a real bug or a design/implementation as expected?

Original report by Batte HUCHAI (Bitbucket: bhuchai, ).

Hello,

When I try to compile my QT code (including EFSW), I get these kind of compiling errors :

#!c++
C:/MCF/MCF/Tools/efsw/libs//libefsw-static-release-win.a(FileWatcherWin32.o):FileWatcherWin32.cpp:(.text+0x4a2): undefined reference to `std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)'
C:/MCF/MCF/Tools/efsw/libs//libefsw-static-release-win.a(FileWatcherGeneric.o):FileWatcherGeneric.cpp:(.text+0xf9): undefined reference to `std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)'
C:/MCF/MCF/Tools/efsw/libs//libefsw-static-release-win.a(FileWatcherGeneric.o):FileWatcherGeneric.cpp:(.text+0x209): undefined reference to `std::__detail::_List_node_base::_M_unhook()'
C:/MCF/MCF/Tools/efsw/libs//libefsw-static-release-win.a(FileWatcherGeneric.o):FileWatcherGeneric.cpp:(.text+0x29c): undefined reference to `std::__detail::_List_node_base::_M_unhook()'
C:/MCF/MCF/Tools/efsw/libs//libefsw-static-release-win.a(FileWatcherGeneric.o):FileWatcherGeneric.cpp:(.text+0x70d): undefined reference to `std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)'
C:/MCF/MCF/Tools/efsw/libs//libefsw-static-release-win.a(DirectorySnapshot.o):DirectorySnapshot.cpp:(.text+0x13d): undefined reference to `std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)'
C:/MCF/MCF/Tools/efsw/libs//libefsw-static-release-win.a(DirectorySnapshot.o):DirectorySnapshot.cpp:(.text+0x1ce): undefined reference to `std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)'
C:/MCF/MCF/Tools/efsw/libs//libefsw-static-release-win.a(DirectorySnapshot.o):DirectorySnapshot.cpp:(.text+0x631): undefined reference to `std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)'
C:/MCF/MCF/Tools/efsw/libs//libefsw-static-release-win.a(DirectorySnapshot.o):DirectorySnapshot.cpp:(.text+0xf8a): undefined reference to `std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)'
C:/MCF/MCF/Tools/efsw/libs//libefsw-static-release-win.a(DirectorySnapshot.o):DirectorySnapshot.cpp:(.text+0x10b9): more undefined references to `std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)' follow
collect2: ld returned 1 exit status
mingw32-make[1]: Leaving directory `C:/MCF/MCF-build-Qt_4_7_4_MinGW-Debug'
mingw32-make[1]: *** [debug\MCF.exe] Error 1
mingw32-make: *** [debug] Error 2
15:54:26: Le processus "C:\MinGW\MinGW 4.4\bin\mingw32-make.exe" s'est terminé avec le code 2.
Error while building/deploying project MCF (kit: Qt 4.7.4 MinGW)
Lors de l'exécution de l'étape "Make"

Do you have any idea why ?

Thank you very much by advance,

B.

Original report by Kevin Jurkowski (Bitbucket: Driklyn, GitHub: Driklyn).

If you start watching a directory, then delete a file, and re-add it by undoing it (Ctrl+Z), both an added and a modified event is fired.

If you delete a file, then rename another file to match that delete file's name, both a moved and modified event is fired.

Seems like the modified event should not be triggered.

Original report by Yash pal (Bitbucket: codeyash, GitHub: codeyash).

I've created this pro file. Tested for 3 platforms. (Win,Linux,Mac)
Not tested for BSD.

You can include it with library source code. I'm ready to provide support for this build system.

#!makefile

#Yash Speedovation.com | KineticWing.com
#code.YASH  @ G M**L Com
#MIT License

INCLUDEPATH += $$PWD \
                ThirdParty/FileSystemWatcher/src \
                ThirdParty/FileSystemWatcher/include


DEPENDPATH += $$PWD \
                ThirdParty/FileSystemWatcher/src \
                ThirdParty/FileSystemWatcher/include


SOURCES += \
    ThirdParty/FileSystemWatcher/src/efsw/Debug.cpp \
    ThirdParty/FileSystemWatcher/src/efsw/DirectorySnapshot.cpp \
    ThirdParty/FileSystemWatcher/src/efsw/DirectorySnapshotDiff.cpp \
    ThirdParty/FileSystemWatcher/src/efsw/DirWatcherGeneric.cpp \
    ThirdParty/FileSystemWatcher/src/efsw/FileInfo.cpp \
    ThirdParty/FileSystemWatcher/src/efsw/FileSystem.cpp \
    ThirdParty/FileSystemWatcher/src/efsw/FileWatcher.cpp \
    ThirdParty/FileSystemWatcher/src/efsw/FileWatcherCWrapper.cpp \
    ThirdParty/FileSystemWatcher/src/efsw/FileWatcherGeneric.cpp \
    ThirdParty/FileSystemWatcher/src/efsw/FileWatcherImpl.cpp \
    ThirdParty/FileSystemWatcher/src/efsw/Log.cpp \
    ThirdParty/FileSystemWatcher/src/efsw/Mutex.cpp \
    ThirdParty/FileSystemWatcher/src/efsw/String.cpp \
    ThirdParty/FileSystemWatcher/src/efsw/System.cpp \
    ThirdParty/FileSystemWatcher/src/efsw/Thread.cpp \
    ThirdParty/FileSystemWatcher/src/efsw/Utf.inl \
    ThirdParty/FileSystemWatcher/src/efsw/Watcher.cpp \
    ThirdParty/FileSystemWatcher/src/efsw/WatcherGeneric.cpp



HEADERS += \
    ThirdParty/FileSystemWatcher/include/efsw/efsw.h \
    ThirdParty/FileSystemWatcher/include/efsw/efsw.hpp \
    ThirdParty/FileSystemWatcher/src/efsw/base.hpp \
    ThirdParty/FileSystemWatcher/src/efsw/Debug.hpp \
    ThirdParty/FileSystemWatcher/src/efsw/DirectorySnapshot.hpp \
    ThirdParty/FileSystemWatcher/src/efsw/DirectorySnapshotDiff.hpp \
    ThirdParty/FileSystemWatcher/src/efsw/DirWatcherGeneric.hpp \
    ThirdParty/FileSystemWatcher/src/efsw/FileInfo.hpp \
    ThirdParty/FileSystemWatcher/src/efsw/FileSystem.hpp \
    ThirdParty/FileSystemWatcher/src/efsw/FileWatcherGeneric.hpp \
    ThirdParty/FileSystemWatcher/src/efsw/FileWatcherImpl.hpp \
    ThirdParty/FileSystemWatcher/src/efsw/Mutex.hpp \
    ThirdParty/FileSystemWatcher/src/efsw/sophist.h \
    ThirdParty/FileSystemWatcher/src/efsw/String.hpp \
    ThirdParty/FileSystemWatcher/src/efsw/System.hpp \
    ThirdParty/FileSystemWatcher/src/efsw/Thread.hpp \
    ThirdParty/FileSystemWatcher/src/efsw/Utf.hpp \
    ThirdParty/FileSystemWatcher/src/efsw/Watcher.hpp \
    ThirdParty/FileSystemWatcher/src/efsw/WatcherGeneric.hpp \
    ThirdParty/FileSystemWatcher/src/efsw/platform/platformimpl.hpp



win32{

    DEPENDPATH +=  ThirdParty/FileSystemWatcher/src/efsw/platform/win
    INCLUDEPATH +=  ThirdParty/FileSystemWatcher/src/efsw/platform/win

     HEADERS += \
        ThirdParty/FileSystemWatcher/src/efsw/WatcherWin32.hpp \
        ThirdParty/FileSystemWatcher/src/efsw/FileWatcherWin32.hpp \
        ThirdParty/FileSystemWatcher/src/efsw/platform/win/FileSystemImpl.hpp \
        ThirdParty/FileSystemWatcher/src/efsw/platform/win/MutexImpl.hpp \
        ThirdParty/FileSystemWatcher/src/efsw/platform/win/SystemImpl.hpp \
        ThirdParty/FileSystemWatcher/src/efsw/platform/win/ThreadImpl.hpp

    SOURCES += \
        ThirdParty/FileSystemWatcher/src/efsw/WatcherWin32.cpp \
        ThirdParty/FileSystemWatcher/src/efsw/FileWatcherWin32.cpp \
        ThirdParty/FileSystemWatcher/src/efsw/platform/win/FileSystemImpl.cpp \
        ThirdParty/FileSystemWatcher/src/efsw/platform/win/MutexImpl.cpp \
        ThirdParty/FileSystemWatcher/src/efsw/platform/win/SystemImpl.cpp \
        ThirdParty/FileSystemWatcher/src/efsw/platform/win/ThreadImpl.cpp

} unix {

    DEPENDPATH +=  ThirdParty/FileSystemWatcher/src/efsw/platform/posix
    INCLUDEPATH +=  ThirdParty/FileSystemWatcher/src/efsw/platform/posix

    HEADERS += \
        ThirdParty/FileSystemWatcher/src/efsw/platform/posix/FileSystemImpl.hpp \
        ThirdParty/FileSystemWatcher/src/efsw/platform/posix/MutexImpl.hpp \
        ThirdParty/FileSystemWatcher/src/efsw/platform/posix/SystemImpl.hpp \
        ThirdParty/FileSystemWatcher/src/efsw/platform/posix/ThreadImpl.hpp

    SOURCES += \
        ThirdParty/FileSystemWatcher/src/efsw/platform/posix/FileSystemImpl.cpp \
        ThirdParty/FileSystemWatcher/src/efsw/platform/posix/MutexImpl.cpp \
        ThirdParty/FileSystemWatcher/src/efsw/platform/posix/SystemImpl.cpp \
        ThirdParty/FileSystemWatcher/src/efsw/platform/posix/ThreadImpl.cpp

    linux{

        HEADERS += \
                ThirdParty/FileSystemWatcher/src/efsw/inotify-nosys.h \
                ThirdParty/FileSystemWatcher/src/efsw/FileWatcherInotify.hpp \
                ThirdParty/FileSystemWatcher/src/efsw/WatcherInotify.hpp \

        SOURCES += \
                ThirdParty/FileSystemWatcher/src/efsw/FileWatcherInotify.cpp \
                ThirdParty/FileSystemWatcher/src/efsw/WatcherInotify.cpp

    }

    macx{

        LIBS+= -framework CoreFoundation -framework CoreServices

       HEADERS += \
            ThirdParty/FileSystemWatcher/src/efsw/FileWatcherKqueue.hpp \
            ThirdParty/FileSystemWatcher/src/efsw/WatcherFSEvents.hpp \
            ThirdParty/FileSystemWatcher/src/efsw/FileWatcherFSEvents.hpp \
            ThirdParty/FileSystemWatcher/src/efsw/WatcherKqueue.hpp

        SOURCES += ThirdParty/FileSystemWatcher/src/efsw/WatcherKqueue.cpp \
            ThirdParty/FileSystemWatcher/src/efsw/WatcherFSEvents.cpp \
            ThirdParty/FileSystemWatcher/src/efsw/FileWatcherFSEvents.cpp \
            ThirdParty/FileSystemWatcher/src/efsw/FileWatcherKqueue.cpp
    }

}

OTHER_FILES += \
    ThirdParty/FileSystemWatcher/CMakeLists.txt

Original report by Nils Desle (Bitbucket: nilsdesle, ).

After fixing issue 34 locally, I'm now working with the generic watcher on windows, and its behaviour is not as I expect.

Using the test application, in generic mode (Windows 7), here's the scenario:

1. Inside the watched folder, create a new folder "Level1"
2. Observe that this is detected
3. Inside "Level1", create "Level2"
4. Observe that this is detected
5. Inside "Level2", create "Level3"
6. Observe that this is detected
7. Inside "Level3", create "Level4"
8. Observe that this is detected
9. Inside "Level4", create a file "bla.txt"
10. Observe that this is detected
11. Delete all files and folders at once (Shift-del on "Level1" in explorer)
12. Observe that each folder and file gets a DELETE event

so far so good

13. Create the same folder/file structure OUTSIDE of the watched folder
14. Copy the entire folder structure "Level1" over to the watched folder in one go, using windows explorer
15. Observe that only "Level1" gets an added notification, and nothing else is detected

Not what I expected

16. Add file "test.txt" to "Level4"
17. Observe that NO notification is made, so this new file is not seen or reported

Again, not what I expected

18. Add file "test.txt" to "Level1"
19. Observe that this aded file is reported normally
20. Delete the enire folder structure "Level1" in one go
21. Observe that you get a Delete event for "Level1", "Level1\test.txt" AND a delete event for the "Level2" folder and nothing else (note that "Level2" was never reported as being created!)

Any idea why all this is happening? Combined with issue #34 and #35, I'm getting quite worried here...

Original report by Mihail Slobodyanuk (Bitbucket: mihail_slobodyanuk, ).

Need to explain how to I used this one.
I used efsw in project which should start on many different NAS devices. For each device i build project on defferent toolchains. Sometimes it's have old OS and old GLIBC but new kernel. That's why i need inotify-nosys.h to perform direct syscalls.

I see you added conditional inclusion of inotify-nosys.h in premake4.lua:

if os.is("linux") and not os.isfile("/usr/include/sys/inotify.h") and not os.isfile("/usr/local/include/sys/inotify.h") then
defines { "EFSW_INOTIFY_NOSYS" }
end

I am sorry but it seems direct paths can't properly checked when build on toolchan. Need to found another way to checking.
Thanks.

Original report by Karol Woźniak (Bitbucket: KenjiTakahashi, GitHub: KenjiTakahashi).

I'd like to get a whole old path for moved file/dir, instead of just a basename. I have a K/V storage with paths as keys and when something is moved I'd like to remove old entry.

I know I can do it myself by tracking WatchIDs, but maybe there's an easy way to implement it inside efsw.

Original report by Mihail Slobodyanuk (Bitbucket: mihail_slobodyanuk, ).

isDirectory() check in FileWatcherWin32.cpp:46 return false.
Compiled on Mingw32.

Original report by Yash pal (Bitbucket: codeyash, GitHub: codeyash).

May be I'm missing something but

DIR = "N:/Projects/www/vertis" FILE = "jade" has event Delete

Now jade was folder and not file. May be vice versa. Is there any way we know deleted was folder or file?

Sorry for posting. I don't find any forum for discussion like this.

Original report by Sarvagya Pant (Bitbucket: sarvpant, ).

I have been successful in running this library using visual studio but the same is giving me Intellisense and namespace error when making the dll. I have following CMakeLists.txt file:

#!Makefile

SET(TARGET integrity_monitor)
message("\n Building ${TARGET}")
cmake_policy(SET CMP0015 NEW)
project(${TARGET})

SET(SOURCE
  IntegrityMonitor.cpp 
)

SET(HEADERS
  IntegrityMonitor.h ../BaseApplication.hpp 
)

include_directories("..\\..\\..\\ext_library\\SpartanJ-efsw-linux\\src")
include_directories("..\\..\\..\\ext_library\\SpartanJ-efsw-linux\\include")
LINK_DIRECTORIES("..\\..\\..\\ext_library\\SpartanJ-efsw-linux\\lib")

set(Boost_USE_STATIC_LIBS       OFF)
set(Boost_USE_MULTITHREADED      ON)
set(Boost_USE_STATIC_RUNTIME    OFF)
find_package(Boost 1.55.0 COMPONENTS thread filesystem system)

if(Boost_FOUND)
    add_definitions(-DDLL_EXPORTS)
    add_definitions(-DBOOST_ALL_DYN_LINK)
    include_directories("..\\..\\..\\ext_library\\zmq\\zeromq-4.0.3\\include")
    include_directories("..\\..\\..\\ext_library\\zmq\\czmq\\czmq-2.1.0\\include")
    link_directories("..\\..\\..\\ext_library\\zmq\\zeromq-4.0.3\\lib\\Win32\\Debug")
    link_directories("..\\..\\..\\ext_library\\zmq\\czmq\\czmq-2.1.0\\lib\\Win32\\DebugDLL")
    include_directories(${Boost_INCLUDE_DIRS})
    LINK_DIRECTORIES(${Boost_LIBRARY_DIRS})
    add_library(${TARGET} SHARED ${SOURCE} ${HEADERS})
    target_link_libraries(${TARGET} ${Boost_LIBRARIES} czmq efsw-static-debug)
    
else()
    message(STATUS "Boost_FOUND False")
endif()

Basically the problem is, the same code runs when compiled as executable, but gives intellisense errors in Visual studio 10 when created a DLL. Do I need to add something in my CMakeLists.txt file

Original report by Mihail Slobodyanuk (Bitbucket: mihail_slobodyanuk, ).

Linux buld.
I set followSymlinks false
But newly created recursive link (link "." ) in watched directory is taken into account and lead to infinity recursion

Original report by Yash pal (Bitbucket: codeyash, GitHub: codeyash).

terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc

Crashes suddenly during monitoring files.

Attached backtraces. Let me know if anything else required.

Original report by Anonymous.

I generated GMake script by command:

$premake4 gmake

then i run:
make config=release LDFLAGS="-L<toolchain's_lib_path>" CFLAGS="-I<toolchain's_include_path>" -f efsw-static-lib.make

when internal assigment to LDFLAGS and CFLAGS in efsw-static-lib.make is purged because defined without 'override' directive.
Maybe it's premake issue, or it need deeper configuring.

Howbeit it's very important issue for crossplatform project like this

Original report by Mihail Slobodyanuk (Bitbucket: mihail_slobodyanuk, ).

Maybe i have implemented wrong usecase of EFSW but i found following issue:

I use EFSW to detect FS changes then waiting for finishing changes then transfer changes to cloud storage. I am process files only after "sanitize" delay after last modify event (30 sec) to ensure file changes was finished.

But i found EFSW not subscribed to IN_MODIFY event (FileWatcherInotify.cpp:128).
And i have less info about changes.

Case 1)
The command:

dd if=/dev/urandom bs=1M count=1500 of=file

issue two events: 'Add' on start and file creatin then 'Modified' after file closed. If command execution time > 30 sec then my code will take file into accouns as finished.
Ok. Maybe i don't need to handle 'Add' but

Case 2)
Renaming file:

mv file1 file2

Issued 'Delete' for file1 then 'Add' for file2 and no more.

Looks like IN_MODIFY is required?

Original report by Jacob Howard (Bitbucket: havoc-io, GitHub: havoc-io).

It appears that the compiler flag conditional in CMakeLists.txt is inverted. It currently reads

if (MSVC)
    add_definitions(-Wall)
else ()
    add_definitions(-D_SCL_SECURE_NO_WARNINGS)
endif()

It should actually be the other way around (the -D_SCL_SECURE_NO_WARNINGS flag only makes sense for MSVC)

if (MSVC)
    add_definitions(-D_SCL_SECURE_NO_WARNINGS) 
else ()
    add_definitions(-Wall)
endif()

In fact, it should actually read

if (MSVC)
    add_definitions(-D_SCL_SECURE_NO_WARNINGS) 
else ()
    add_definitions(-Wall -Wno-long-long)
endif()

It looks like what happened is that the conditional was originally in the incorrect order (someone tried to mimic the order of the premake file where the condition is equivalent to NOT MSVC). That didn't work on Windows, so in commit c6cde00 the -Wno-long-long flag was removed to make it barely work. MSVC does understand the -Wall flag, but on Windows this causes all warnings to become active, unlike in GCC/Clang where only a sensible subset become active, so the code builds on Windows, but it spits out a very large number of warnings.

Anyway, all that needs to happen is that the flags should be swapped and the -Wno-long-long flag should probably be added back in to keep consistency with premake.

I apologize for not issuing this as a pull request, but I'm really unfamiliar with Mercurial.

Original report by Yash pal (Bitbucket: codeyash, GitHub: codeyash).

I would to include in Qt project. I don't use cmake or similar build systems. I use Qt pro files.

Please create a pri or pro file so that integration becomes easy.

We may use subdir of qmake.

I may create one and share with you.

Thanks for this wonderful library. Missing features in Qt. Inbuilt one is full of bugs.

Best of luck

Thanks
Yash
KineticWing.com

Original report by Batte HUCHAI (Bitbucket: bhuchai, ).

Hello,

I have a problem of char encoding on Windows 7. Indeed, when I create a file with Windows Explorer which contains a special char (no ASCII or "basic" char ...) like "♫" (for example) in its name, the EFSW FileWatcher gives to my application the same filename but with a "?" char instead of "♫" :

For example, when I create the file "test♫.xlsx", I get :

DIR (C:\Users\buchet\Documents\Watched\) FILE (test?.xlsx) has event Added

It can be stupid to have a filename with a "♫" but it's just an example. It's the same thing with all special chars which are accepted by Windows Explorer but are "modified" by EFSW naming ...

For your information, it seems working in Mac OS 1.7.5.

Any idea ?