4 ms·

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
nickcano 12y ago
Well, it's not 'scanning files'. It's scanning meta-data about directories and files. You can see three calls for each file in the ProcMon logs: 1. CreateFile 2. QueryBasicInformationFile 3. CloseFile Let's go through these in order: 1. Opens a handle to the file, allowing the application to query meta information, read, and write 2. Queries meta information about the file. 3. Closes the handle to the file before doing anything else, including reading data. There's no scanning of files, because no data is read. Its common for applications to traverse directories like this, and the behavior could even be a consequence of a file system library or API that dropbox is using. If you think of your file system as a filing cabinet, what DropBox is doing might be equivalent to opening every drawer looking for a single file. ProcMon detects CreateFile and QueryInformationFile using these function codes: https://msdn.microsoft.com/en-us/library/ff548630(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/ff548630(v=vs.85).a... https://msdn.microsoft.com/en-us/library/ff549283.aspx https://msdn.microsoft.com/en-us/library/ff549283.aspx As you can see, neither of these indicates a file being read. It also monitors a number of other codes (I'm not sure how specifically it detects CloseFile), including this one, which is triggered when data is read from a file: https://msdn.microsoft.com/en-us/library/ff549327(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/ff549327(v=vs.85).a... If that was being called, ProcMon would show it, but it doesn't

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

nickcano 12y ago

Well, it's not 'scanning files'. It's scanning meta-data about directories and files. You can see three calls for each file in the ProcMon logs: 1. CreateFile 2. QueryBasicInformationFile 3. CloseFile Let's go through these in order: 1. Opens a handle to the file, allowing the application to query meta information, read, and write 2. Queries meta information about the file. 3. Closes the handle to the file before doing anything else, including reading data. There's no scanning of files, because no data is read. Its common for applications to traverse directories like this, and the behavior could even be a consequence of a file system library or API that dropbox is using. If you think of your file system as a filing cabinet, what DropBox is doing might be equivalent to opening every drawer looking for a single file. ProcMon detects CreateFile and QueryInformationFile using these function codes: https://msdn.microsoft.com/en-us/library/ff548630(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/ff548630(v=vs.85).a... https://msdn.microsoft.com/en-us/library/ff549283.aspx https://msdn.microsoft.com/en-us/library/ff549283.aspx As you can see, neither of these indicates a file being read. It also monitors a number of other codes (I'm not sure how specifically it detects CloseFile), including this one, which is triggered when data is read from a file: https://msdn.microsoft.com/en-us/library/ff549327(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/ff549327(v=vs.85).a... If that was being called, ProcMon would show it, but it doesn't