4 ms·

Tracking Changes in Directories with Python

32 points by tsileo 13y ago

TeamIndia 13y ago
If you do not want to pay for the overhead, I recommend inotify-tools. They have Python bindings too: https://github.com/seb-m/pyinotify https://github.com/seb-m/pyinotify
netnichols 13y ago
Since he asks for feedback at the end... Using sha256 just to compute changes is probably overkill. Using md5 instead is almost certainly adequate and will be a good deal faster.
- pudquick 13y ago
  > good deal faster You could always try it and see :) Example test: openssl speed md5 sha256 As for why it was chosen, I think it's because there are known examples of MD5 hash collisions (though the likelihood of it on a filesystem is remote) and likely SHA-1 was skipped because it's considered 'likely' a collision could be created (though so far only with weakened versions of SHA-1). But - all this to say: The chances of having two files with the same MD5 hash that are identical in size is vanishingly small. As such, for the known MD5 collision mechanisms, the different file size would be enough evidence something has changed. ... Why he didn't include file size in the metadata check, I can't tell you. Timestamps can be faked - but generating a hash collision with a file of equal size is a Hard problem.
  - tsileo 13y ago
    Thanks for the feedback! I haven't thought about the filesize/hash to reduce collision, but I chose to stick with the last-modified time in the article, because it can takes hours computing hashes for a big directory tree. Tools like rsync relies on last-modified time by default, and since I want to use this to track my own files, I won't fake it, so I think it's not a big deal?
    - netnichols 13y ago
      It's not just that it could be faked, it could be an accident that you modify a file but the file modification date is not changed. For example, say you edit a photo, but later you run a script that sets the file's modification date to the EXIF data in the photo. So I guess the point is that also including the file size will be one more (fast) data point to help ensure 'accurate' change tracking, without adding the overhead of computing content hashes.
      - tsileo 13y ago
        I think I will add the file size to the index, since it's really cheap. Thanks!
  - dded 13y ago
    >> good deal faster >> You could always try it and see :) >> Example test: openssl speed md5 sha256 When I was looking for a fast hash easily called from Python, I settled on adler32 (as the fastest) after some trial-and-error on my files. I don't now recall all the utilities/functions that I tried, but they certainly included md5, sha1, and crc32. I only needed to test for accidental corruption, and only computed the hashes if meta data matched.
- olavgg 13y ago
  Don't use MD5, user SipHash https://131002.net/siphash/ https://131002.net/siphash/
yummyfajitas 13y ago
I can't tell exactly what the goal is, but inotify might also be a simpler solution. (Specifically, if the goal is to monitor changes as they happen and the service can be assumed to be continually running.)
- arethuza 13y ago
  And the command line inotifywait - which I've used from Python to monitor changes to directories. There is even a Windows port: https://github.com/thekid/inotify-win https://github.com/thekid/inotify-win
  - icebraining 13y ago
    pyinotify is also pretty simple to use: https://github.com/seb-m/pyinotify https://github.com/seb-m/pyinotify
    - arethuza 13y ago
      Thanks, I was after something that would work from Python on Linux and Windows and calling out to inotifywait seemed to work well for that - this is for my home grown RESTful Dropbox-lite application which is sitting at 95% complete...
- tsileo 13y ago
  The service is not continually running, I use this method to make incremental backups with archives stored on AWS Glacier and meta-data stored on S3 (the index is stored on S3, and I can't access files on Glacier to compute deltas).
  - aray 13y ago
    I'm not sure what you mean by continually running, but inotifywait is basically just waiting on an event. As long as the process sticks around it doesn't have to do anything until it gets an inotify.
johtso 13y ago
The watchdog library is great for this. It comes with an API and a command line tool: https://github.com/gorakhargosh/watchdog https://github.com/gorakhargosh/watchdog Compatibility: Linux 2.6 (inotify) Mac OS X (FSEvents, kqueue) FreeBSD/BSD (kqueue) Windows (ReadDirectoryChangesW with I/O completion ports; ReadDirectoryChangesW worker threads) OS-independent (polling the disk for directory snapshots and comparing them periodically; slow and not recommended)

32 points by tsileo 13y ago

If you do not want to pay for the overhead, I recommend inotify-tools. They have Python bindings too: https://github.com/seb-m/pyinotify https://github.com/seb-m/pyinotify

netnichols 13y ago

Since he asks for feedback at the end... Using sha256 just to compute changes is probably overkill. Using md5 instead is almost certainly adequate and will be a good deal faster.

pudquick 13y ago
> good deal faster You could always try it and see :) Example test: openssl speed md5 sha256 As for why it was chosen, I think it's because there are known examples of MD5 hash collisions (though the likelihood of it on a filesystem is remote) and likely SHA-1 was skipped because it's considered 'likely' a collision could be created (though so far only with weakened versions of SHA-1). But - all this to say: The chances of having two files with the same MD5 hash that are identical in size is vanishingly small. As such, for the known MD5 collision mechanisms, the different file size would be enough evidence something has changed. ... Why he didn't include file size in the metadata check, I can't tell you. Timestamps can be faked - but generating a hash collision with a file of equal size is a Hard problem.
- tsileo 13y ago
  Thanks for the feedback! I haven't thought about the filesize/hash to reduce collision, but I chose to stick with the last-modified time in the article, because it can takes hours computing hashes for a big directory tree. Tools like rsync relies on last-modified time by default, and since I want to use this to track my own files, I won't fake it, so I think it's not a big deal?
  - netnichols 13y ago
    It's not just that it could be faked, it could be an accident that you modify a file but the file modification date is not changed. For example, say you edit a photo, but later you run a script that sets the file's modification date to the EXIF data in the photo. So I guess the point is that also including the file size will be one more (fast) data point to help ensure 'accurate' change tracking, without adding the overhead of computing content hashes.
    - tsileo 13y ago
      I think I will add the file size to the index, since it's really cheap. Thanks!
- dded 13y ago
  >> good deal faster >> You could always try it and see :) >> Example test: openssl speed md5 sha256 When I was looking for a fast hash easily called from Python, I settled on adler32 (as the fastest) after some trial-and-error on my files. I don't now recall all the utilities/functions that I tried, but they certainly included md5, sha1, and crc32. I only needed to test for accidental corruption, and only computed the hashes if meta data matched.
olavgg 13y ago
Don't use MD5, user SipHash https://131002.net/siphash/ https://131002.net/siphash/

yummyfajitas 13y ago

I can't tell exactly what the goal is, but inotify might also be a simpler solution. (Specifically, if the goal is to monitor changes as they happen and the service can be assumed to be continually running.)

arethuza 13y ago
And the command line inotifywait - which I've used from Python to monitor changes to directories. There is even a Windows port: https://github.com/thekid/inotify-win https://github.com/thekid/inotify-win
- icebraining 13y ago
  pyinotify is also pretty simple to use: https://github.com/seb-m/pyinotify https://github.com/seb-m/pyinotify
  - arethuza 13y ago
    Thanks, I was after something that would work from Python on Linux and Windows and calling out to inotifywait seemed to work well for that - this is for my home grown RESTful Dropbox-lite application which is sitting at 95% complete...
tsileo 13y ago
The service is not continually running, I use this method to make incremental backups with archives stored on AWS Glacier and meta-data stored on S3 (the index is stored on S3, and I can't access files on Glacier to compute deltas).
- aray 13y ago
  I'm not sure what you mean by continually running, but inotifywait is basically just waiting on an event. As long as the process sticks around it doesn't have to do anything until it gets an inotify.

johtso 13y ago

The watchdog library is great for this. It comes with an API and a command line tool: https://github.com/gorakhargosh/watchdog https://github.com/gorakhargosh/watchdog Compatibility: Linux 2.6 (inotify) Mac OS X (FSEvents, kqueue) FreeBSD/BSD (kqueue) Windows (ReadDirectoryChangesW with I/O completion ports; ReadDirectoryChangesW worker threads) OS-independent (polling the disk for directory snapshots and comparing them periodically; slow and not recommended)