7 ms·

In Windows, even with a filter limiting which directories to process, a FileSystemWatcher object has to examine each event and decide whether or not to call the

In Windows, even with a filter limiting which directories to process, a FileSystemWatcher object has to examine each event and decide whether or not to call the event handler or let it pass without action. That means it would have to read the file information and compare it against the filters that have been defined. These actions will show up as at least 4 or 5 entries in Process Monitor (and maybe more, I'm not sure off the top of my head). This also means that applications monitoring for file access will catch each time this happens. Unfortunately, whoever wrote that article does not seem to understand Window's internals, or how to determine what consists of bad or dangerous activity. It should also be noted that Dropbox runs in the context of your own user account. It does not run as a service or elevated user, so it will only have access to the files you have access to (and that you have access to without requiring elevation). I'm not going to claim to be a security expert, but I don't see anything that would suggest a security risk on Dropbox's part. Further, if a company has data important enough that they need to run DLP software on individual computers, they should not be allowing software such as Dropbox anyway.

tomp 12y ago
This explains the first part (Dropbox accessing the files), but not the second part (synchronous network activity).
- umurkontaci 12y ago
  Dropbox is always connected and continually checks for updates, just because one sees at the same time doesn't mean they are related. I see Dropbox connections all the time whenever I look through my network.
  - atmosx 12y ago
    I am on mac, I have littlesnitch and I also have Geektool display network connections. Dropbox is not always "active". I don't see any kind of network traffic after syncing has been done under macosx.
    - dr_gustavo 12y ago
      This can be simply analytics event tracking.
    - ohitsdom 12y ago
      It needs to at least be periodically active to sync in case you add a file with another device.
      - lucb1e 12y ago
        Periodically yes, but open TCP connections can technically last for days (although this is implementation-specific) without any packets being sent across. You're right of course, periodic data needs to be sent even if just to keep the TCP connection open, but it's not much and it's not often.
- vsl 12y ago
  Correlation does not imply causation.
SpaceInvader 12y ago
Why it is scanning files outside of the agreed location?
- yohui 12y ago
  Doesn't tallavor address this in the first sentence? > In Windows, even with a filter limiting which directories to process, a FileSystemWatcher object has to examine each event and decide whether or not to call the event handler or let it pass without action. Sounds like the very act of checking whether the file falls within the "agreed location" is what caught the author's attention. I can't say whether that's true, but it doesn't seem unreasonable.
  - SpaceInvader 12y ago
    It was rhetorical question :)
- tallanvor 12y ago
  It depends on the method they're using to monitor for changes to files and the type of filter being used. They're probably trying to reuse code across clients, so I'm not sure what method they're using. --ReadDirectoryChangesW makes the most sense, but maybe they've done it differently. If someone really wants to figure it out, it's probably possible to attach a debugger to try and catch the calls being used, but since we don't have symbols, it wouldn't be the easiest exercise (although it might be fun if I could find the time).
  - greenleafjacob 12y ago
    You don't need debugging symbols to trace system calls.
- _razvan 12y ago
  What happens here is that Windows Explorer asks Dropbox whether it should display a green or blue icon for a file. It does this for all files, including those outside of the Dropbox folder. Full analysis here: https://news.ycombinator.com/item?id=9139657 https://news.ycombinator.com/item?id=9139657
huhtenberg 12y ago
> FileSystemWatcher That's a .Net contraption over one of two Win32 APIs that provide file system monitoring services. Neither of these requires opening files in response to file system notifications. That's 100%, guaranteed. Correct me if I wrong but Dropbox is not written in .Net, so what you said is irrelevant. -- APIs in question: [1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa364417%28v=vs.85%29.aspx https://msdn.microsoft.com/en-us/library/windows/desktop/aa3... [2] https://msdn.microsoft.com/en-us/library/windows/desktop/aa365465%28v=vs.85%29.aspx https://msdn.microsoft.com/en-us/library/windows/desktop/aa3...
- tallanvor 12y ago
  I'm not sure if Dropbox is managed code or not. FileSystemWatcher does implement ReadDirectoryChangesW, which would allow them to set specific directories to watch. They may be using change journals instead, though, which function differently. Either way, I'm fairly certain that checking file properties (as would be done to check whether or not a filter applies) would be registered as opening the file.
  - huhtenberg 12y ago
    Change journals are read from the volume directly and there's no evidence in the ProcMon logs (posted elsewhere here) that Dropbox uses them. > I'm fairly certain that checking file properties (as would be done to check whether or not a filter applies) would be registered as opening the file. Bzzt, nope. Wrong again. You should really try and not comment on things that you are not well-versed at. This part in particular - "as would be done to check whether or not a filter applies" - makes no sense. Dropbox has the file path readily available from the notification itself [1], and that's the only thing they need to look at to determine if the file is in their managed directory or not. [1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa364391%28v=vs.85%29.aspx https://msdn.microsoft.com/en-us/library/windows/desktop/aa3... Point being that the app does not need to open files when processing file system notifications, which is what you stated in the top comment.
    - geofft 12y ago
nissehulth 12y ago
I don't think this is related to FileSystemWatcher (or ReadDirectoryChangesW) at all. I believe the author is just confused by the shell extension. Every time you right click a file in explorer, this type of "file access" would happen.
- lucb1e 12y ago
  But then an explorer.exe process would access the file, not Dropbox. The screenshots clearly show that it detected Dropbox accessing something.
deleted 12y ago
[deleted]

tomp 12y ago

This explains the first part (Dropbox accessing the files), but not the second part (synchronous network activity).

umurkontaci 12y ago
Dropbox is always connected and continually checks for updates, just because one sees at the same time doesn't mean they are related. I see Dropbox connections all the time whenever I look through my network.
- atmosx 12y ago
  I am on mac, I have littlesnitch and I also have Geektool display network connections. Dropbox is not always "active". I don't see any kind of network traffic after syncing has been done under macosx.
  - dr_gustavo 12y ago
    This can be simply analytics event tracking.
  - ohitsdom 12y ago
    It needs to at least be periodically active to sync in case you add a file with another device.
    - lucb1e 12y ago
      Periodically yes, but open TCP connections can technically last for days (although this is implementation-specific) without any packets being sent across. You're right of course, periodic data needs to be sent even if just to keep the TCP connection open, but it's not much and it's not often.
vsl 12y ago
Correlation does not imply causation.

SpaceInvader 12y ago

Why it is scanning files outside of the agreed location?

yohui 12y ago
Doesn't tallavor address this in the first sentence? > In Windows, even with a filter limiting which directories to process, a FileSystemWatcher object has to examine each event and decide whether or not to call the event handler or let it pass without action. Sounds like the very act of checking whether the file falls within the "agreed location" is what caught the author's attention. I can't say whether that's true, but it doesn't seem unreasonable.
- SpaceInvader 12y ago
  It was rhetorical question :)
tallanvor 12y ago
It depends on the method they're using to monitor for changes to files and the type of filter being used. They're probably trying to reuse code across clients, so I'm not sure what method they're using. --ReadDirectoryChangesW makes the most sense, but maybe they've done it differently. If someone really wants to figure it out, it's probably possible to attach a debugger to try and catch the calls being used, but since we don't have symbols, it wouldn't be the easiest exercise (although it might be fun if I could find the time).
- greenleafjacob 12y ago
  You don't need debugging symbols to trace system calls.
_razvan 12y ago
What happens here is that Windows Explorer asks Dropbox whether it should display a green or blue icon for a file. It does this for all files, including those outside of the Dropbox folder. Full analysis here: https://news.ycombinator.com/item?id=9139657 https://news.ycombinator.com/item?id=9139657

huhtenberg 12y ago

> FileSystemWatcher That's a .Net contraption over one of two Win32 APIs that provide file system monitoring services. Neither of these requires opening files in response to file system notifications. That's 100%, guaranteed. Correct me if I wrong but Dropbox is not written in .Net, so what you said is irrelevant. -- APIs in question: [1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa364417%28v=vs.85%29.aspx https://msdn.microsoft.com/en-us/library/windows/desktop/aa3... [2] https://msdn.microsoft.com/en-us/library/windows/desktop/aa365465%28v=vs.85%29.aspx https://msdn.microsoft.com/en-us/library/windows/desktop/aa3...

tallanvor 12y ago
I'm not sure if Dropbox is managed code or not. FileSystemWatcher does implement ReadDirectoryChangesW, which would allow them to set specific directories to watch. They may be using change journals instead, though, which function differently. Either way, I'm fairly certain that checking file properties (as would be done to check whether or not a filter applies) would be registered as opening the file.
- huhtenberg 12y ago
  Change journals are read from the volume directly and there's no evidence in the ProcMon logs (posted elsewhere here) that Dropbox uses them. > I'm fairly certain that checking file properties (as would be done to check whether or not a filter applies) would be registered as opening the file. Bzzt, nope. Wrong again. You should really try and not comment on things that you are not well-versed at. This part in particular - "as would be done to check whether or not a filter applies" - makes no sense. Dropbox has the file path readily available from the notification itself [1], and that's the only thing they need to look at to determine if the file is in their managed directory or not. [1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa364391%28v=vs.85%29.aspx https://msdn.microsoft.com/en-us/library/windows/desktop/aa3... Point being that the app does not need to open files when processing file system notifications, which is what you stated in the top comment.
  - geofft 12y ago

nissehulth 12y ago

I don't think this is related to FileSystemWatcher (or ReadDirectoryChangesW) at all. I believe the author is just confused by the shell extension. Every time you right click a file in explorer, this type of "file access" would happen.

lucb1e 12y ago
But then an explorer.exe process would access the file, not Dropbox. The screenshots clearly show that it detected Dropbox accessing something.

deleted 12y ago

[deleted]