New file from server is not committed due to DownloadNanny blocking the commit because file is 'opened'

[Natalia Bidart]

Consider this scenario:

* in a computer with U1 running, open a file that is already fully synched with your cloud. Be sure to open it with python so the file remains opened at FS level (this will make the DownloadNanny track this file in its self._opened dictionary). In the log you should get:

2012-03-28 15:48:04,889 - ubuntuone.SyncDaemon.EQ - DEBUG - push_event: FS_FILE_OPEN, kwargs: {'path': '/home/nessita/Ubuntu One/padding-go-to-web-button.png'}

* be sure to have the settings use_trash set to True

* remove the file from the web UI

* close the file (f.close() in the python terminal)

* the file deletion will be replicated in you computer, and the file will be moved locally to your trash.

* upload the any file to the *exact same path* as the file you removed in the web

* the file will never be downloaded to your local computer, since the download commit will be blocked by the DownloadNannny. Log entry is:

2012-03-28 15:38:58,410 - ubuntuone.SyncDaemon.DownloadFinishedNanny - DEBUG - Blocked! (opened) share '' node 'a943a299-e5e0-4e2f-a0cc-613bdb2f7856' path '/home/nessita/Ubuntu One/padding-go-to-web-button.png'

On the other hand, if you have the setting use_trash set to False, the file is properly downloaded. That's because when deleting the file, the file descriptor being held by python is still valid and is in a directory tracked by our FS watchs, so when closing the file, the DownloadNanny gets the FS_FILE_CLOSE_NOWRITE and removes the entry from the self._opened dictionary.

When the file is moved to the trash, the file descriptor from python is still valid, when closing the file, the even FS_FILE_CLOSE_NOWRITE will be triggered in the Trash directory, which U1 is not tracking with FS watchers, so the DownloadNanny never removes the entry from its internal structures.