Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wrong Result #7

Closed
xpresso opened this issue Sep 8, 2013 · 10 comments
Closed

Wrong Result #7

xpresso opened this issue Sep 8, 2013 · 10 comments
Labels

Comments

@xpresso
Copy link

xpresso commented Sep 8, 2013

inotifywait -e create,delete,modify,move -mrq C:\Test

When moving C:\Test\TestFolder1\testfile.txt to C:\Test\TestFolder2
It results in c:\Test DELETE TestFolder1\testfile.txt which is wrong,
should be

c:\Test MOVED_FROM TestFolder1\testfile.txt
c:\Test MOVED_TO TestFolder2\testfile.txt

@thekid
Copy link
Owner

thekid commented Sep 9, 2013

Verified.

@thekid
Copy link
Owner

thekid commented Sep 9, 2013

This is going to be a bit tougher:

For example, when a file is moved from one directory to another, several OnChanged and some OnCreated and OnDeleted events might be raised. Moving a file is a complex operation that consists of multiple simple operations, therefore raising multiple events.

http://msdn.microsoft.com/en-us/library/system.io.filesystemwatcher.aspx

Pull requests welcome 😄 :octocat:

thekid added a commit that referenced this issue May 6, 2014
@thekid thekid added the bug label May 6, 2014
@thekid
Copy link
Owner

thekid commented Jan 19, 2015

The fact that one event went missing might have been caused by some events being swallowed. Initial tests suggest this have been fixed:

issue-7

The next thing would be to detect that in fact this was the same file and re-work it to MOVED_FROM / MOVED_TO combination; though not sure this would work.

@IbnSaeed
Copy link

any update ?

@thekid
Copy link
Owner

thekid commented Apr 21, 2015

Sorry, no. This goes over my C# / Windows programming skills (how can I find out testfile.txt was the same file as something deleted when examining the CREATE event?), which is why I'm open to accept any pull requests.

This might be comparable to moving files across partitions on Unix. Although moving files is an atomic operation there, it only applies to the situtation when files are on the same file system (in other cases, it's a cp followed by an rm). Not sure how the original inotify tool handles this...

Anyways: I'm not sure this is possible due to the nature how moving files works on Windows.

@IbnSaeed
Copy link

Alright, thanks.

@blaggacao
Copy link

I would suggest comparing the hashed values. (The technique used in web frameworks to invalidate a cached file, if there has been a minor change by altering the filname, wich contains a hash value.)

I think, knowing C#, which I don't, it's pretty straight forward.

Here is the relevenat part copied from stackoverflow:

You could use MD5CryptoServiceProvider, which will work with text based files as well as binary files.

byte[] myFileData = File.ReadAllBytes(myFileName);
byte[] myHash = MD5.Create().ComputeHash(myFileData);

Or... if you work with large files and do not want to load the whole file into memory:

byte[] myFileData;
using (var md5 = MD5.Create())
using (var stream = File.OpenRead(myFileName))
    myFileData = md5.ComputeHash(stream);

You can compare to byte arrays from two files with Enumerable.SequenceEqual:

myHash1.SequenceEqual(myHash2); 

BTW, thanks for the good work! This is very relevant to boot2docker people working with windows and not beeing able to use fswath library: Connect it with rsync and you can use inotify autoreload features in your development cycle.

@thekid
Copy link
Owner

thekid commented Jul 13, 2015

byte[] myFileData = File.ReadAllBytes(myFileName);

Yes, I'd been thinking about this too. On the downside, this could be quite an issue for a 2 Gigabyte file on a Network drive... but even for smaller checkouts around 10 - 50 Megabytes but say with frequent changes this could be quite a performance hit.

Maybe "fingerprinting" as suggested here, but that would mean keeping all files in memory when starting a watch (because what's the fingerprint of a deleted file? -> it would need to be calculated beforehand).

BTW, thanks for the good work!

You're welcome!

@thekid
Copy link
Owner

thekid commented Jul 13, 2015

Reading through this blog, I'd say: For the usecase you're thinking about I think keeping the intelligence about replicating the changes in rsync is sufficient (it does this kind of fingerprinting AFAIK), and just using this tool to detect that there have been changes.

@blaggacao
Copy link

I was about to say, the -c command of rsync does checksum, but not by default, as it is slow as you suggested... I'm working on a shellscript to do exactly what you suggest, leaving apart the moving case, as for development in case of reordering the file structure a need restarting the server is not that far fetched.

@thekid thekid closed this as completed Jul 9, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants