"Big talk qt Five" implementation of file operation monitoring under Windows and Linux

First, demand analysis:

With the continuous development of rendering business, data transmission has become the biggest factor affecting business time. The reason for this is that data transfer takes a long time. Therefore, relying on the rendering business of the network disk development has become an urgent need to solve the demand. The implementation of the network disk and the current market to implement some of the different, mainly in the client and the server side of the operation needs two-way, that is: the user in the client operation needs to synchronize to the server side in time, the server-side job rendering generated files to synchronize to the client in time. That is, the user does not need to download data separately, but while the job is running, the rendering will be automatically synchronized to the client, greatly reducing the waiting time. Of course, both on the client side and on the server face a problem, namely: to implement the monitoring of file operations, the file operations here include: file (folder) creation, file (folder) deletion, file (folder) renaming, file (folder) movement and other operations. In addition to be able to synchronize the client file modification operation, that is: when the user exits the network disk, modified the original synchronization directory files, when users start the network again through a scan and the MD5 value of the comparison can determine which files have changed, and the changes in time to synchronize the operation to the server. Here, a brief overview of how Windows (client implementation needs) and Linux (server-side implementation required) file monitoring is implemented.

Ii. Analysis of the implementation method of document monitoring

1> implementation of file monitoring under Windows

The principle of implementing file monitoring under Windows is to use Shchangenotifyregister to add the specified window to the system's message monitoring chain so that the registration window can receive notifications from the file system or shell. Before proceeding to the downward note, you need to explain the concept of the Windows Shell namespace (shell name space).

Shell namespace is a standard file system under Windows, it greatly expands the DOS file system, forming a "desktop" as the root of a single file system tree, the original C, D disk and other directory tree into the "My Computer" this shell name control subtree of the next level subtree, and like "Control Panel", "Recycle Bin", " Applications such as "Network Places" and devices such as printers are also virtualized as nodes in the shell namespace. To differentiate itself from the concept of "directory" in DOS, Windows introduces the concept of "folders". The "folder" refers to the non-leaf in the shell namespace tree, which can be either a directory under DOS or a virtual directory such as "Control Panel" or "Recycle Bin".

New "path" PIDL: List of Shell object identifiers. Pidl is an array of element type Itemidlist structure, the number of elements in the array is unknown, but immediately after the end of the array must be a double-byte 0. Each array element represents a layer in the Shell namespace tree (that is, a folder or file), and the previous element in the array represents the parent folder of the latter element. Thus, Pidl is actually a pointer to a block of itemidlist structures that are arranged in a number of sequences, and at the end there is a double-byte zero space. So the type of PIDL is defined by Windows as a pointer to the ITEMIDLIST structure.

The path in DOS is a string, but pidl is a binary structure, so we cannot know directly from Pidl which folder or file it represents, but must call the appropriate function to convert it to a string representing the path. If an absolute pidl is part of the filesystem, then the SHGetPathFromIDList function is called, but if not, the path string cannot be obtained because there is no such path at all in DOS.

Overall: The basic process for implementing file monitoring under Windows is as follows:

is a way of using C + + to implement file monitoring under Windows (as flexible as needed), here is a brief description: 1) Create a modal dialog box with Dialogboxparam, enter the window procedure function, and complete our operation according to various messages in the window function. One of the differences between modal dialogs and non-modal dialogs is that it has a set of its own message pump mechanism, which does not require us to manually write messages again (the non-modal dialog itself receives the message). Interception of user messages, depending on the various stages can be added to our own operations, such as initialization and so on. 2) Gets the pidl of the specified path: The target path of the Shell object identifier, with which to continue the subsequent processing, here is obtained in two ways, one is to use IFileDialog Open dialog box to let the user choose (IFileDialog *pfd), Thus through GetResult (IShellItem *psi; Pfs->getresult (&PSI)) acquires IShellItem object, and then uses QueryInterface (ISHELLITEM2 *_psidrop; Psi->queryinterface (&_psidrop)) Gets the IShellItem2 object, and finally uses it to get Pidl (using Shgetidlistfromobject). 3) Finally, using Shchangenotifyregister to mount the final target form, a directory is added to the system's message chain to obtain information about file operations in the file system or shell. Finally, the information can be parsed out.

There is also a way to directly provide the absolute path to the destination folder, which is obtained to pidl, to attach the form to the system message chain, note: If implemented in Qt, it is easy to get to the Qwidget window handle. The key code is as follows:

void Houqd::registerwindow () {char absolutefolderpath[] = "C:\\openssl";//! gets pidl from the absolute path of the folder: List of Shell object identifiers, that is, in Windows The presentation method in the shell namespace "shell name space". Lpitemidlist myfolderpidl = Parsepidlfrompath (Absolutefolderpath); HRESULT res; IShellItem *psi = null;//! Creates a IShellItem (interface) object, IShellItem interface provides a way to find information about the shell item. //! The Ishell item interface inherits from IUnknown Interfaceres = Shcreateshellitem (null, NULL, MYFOLDERPIDL, &PSI); IShellItem2 *ppsi;//! Retrieves a pointer to a supported interface on an object Psi->queryinterface (&PPSI);//! ======================================= Registration File Monitoring =============================================pidlist_absolute Pidlwatch; HRESULT hr = Shgetidlistfromobject (ppsi, &pidlwatch), if (SUCCEEDED (HR)) {shchangenotifyentry Const entries[] = { Pidlwatch, true};int const Nsources = Shcnrf_shelllevel | Shcnrf_interruptlevel | shcnrf_newdelivery;//! Registration window main function _ulregister = Shchangenotifyregister (_hdlg, Nsources, Shcne_allevents, C_notifymessage, ARRAYSIZE (entries), entries); hr = _ulregister! = 0? S_ok:e_fail;}ShowWindow (sw_hide);//! ====================================================================================}

The specific implementation of Parsepidfrompath is as follows:

Lpitemidlist houqd::P arsepidlfrompath (LPCSTR lpszpath) {//buffer for the path string represented in Unicode code Olechar Szolechar[max_path];//" Desktop "IShellFolder interface pointer Lpshellfolder lpsfdesktop; The returned pidl lpitemidlist LPIFQ; ULONG Uleaten, Ulattribs; HRESULT hres; Get the "desktop" of the Ishellfolderr interface pointer Shgetdesktopfolder (&LPSFDESKTOP); Converts the path string of the ANSI character set to a Unicode string, deposited Szolechar MultiByteToWideChar (cp_acp,mb_precomposed, Lpszpath,-1, Szolechar, sizeof (Szolechar)); The path string in Szolechar is translated into the corresponding pidl, deposited lpifq hres = lpsfdesktop->parsedisplayname (null, NULL, Szolechar, &uleaten, &LPIFQ, &ulattribs); hres = Lpsfdesktop->release (); If the translation fails, returns null if (FAILED (hres))  return null; return LPIFQ;}

Implementation of file monitoring under 2> Linux

Linux is mainly through the inotify implementation of file monitoring. It is a mechanism by which the kernel user notifies the user of the changes in the file system of the space program. In user-like, inotify is used by three system calls and file I/O operations on the returned file descriptor.

1) The first step in using INotify is to create an instance of inotify: int fd = Inotify_init (); Each inotify instance corresponds to a separate sorted queue.

2) int wd = Inotify_add_watch (FD, File_dir_path, mask); Add monitoring of a directory.

3) Delete a monitor: Inotify_rm_watch (FD, WD);

The key code is as follows:

if (m_inotifyfd! = lhfsmc_fd_uncreated_state)        close (M_INOTIFYFD);    //! Inotify_init ()    if ((M_INOTIFYFD = Inotify_init ()) < 0)    {        qdebug () << "[ERROR] Lhfilesystemmonitor :: Start:inotify_init failure. ";        return 0;    }    //! Create a Monitor    if (!) for all saved directories in M_createddirlist. Createwatcherforeachdir (m_createddirlist))    {        qdebug () << "[ERROR] Lhfilesystemmonitor::start: Createnotifierforeachdir failure. ";        return 0;    }

Implementation of Createwatcherforeachdir:

int Lhfilesystemmonitor::createwatcherforeachdir (qstringlist &dirlocationlist) {#ifndef WIN32 for    ( Qstringlist::const_iterator iter = Dirlocationlist.begin ();         Iter! = Dirlocationlist.end ();         ++iter)    {        int watchdescriptor;        if (Watchdescriptor = Createwatcher (Iter->tostdstring (). C_STR ())) > 0)            m_monitoredobjectlist.push_back ( Lhfsmonitordata (*iter, Watchdescriptor));        else            qdebug () << "[ERROR] Lhfilesystemmonitor::createwatcherforeachdir:createwatcher for"                     << * ITER << "failure";    } #endif    return 1;}

Implementation of Createwatcher:

int lhfilesystemmonitor::createwatcher (const char *filelocation) const{    if (filelocation = = NULL)        return 0;    Qdir dir (filelocation);    if (!dir.exists ())    {        qdebug () << "[ERROR] Lhfilesystemmonitor::createnotifier:" << filelocation << "is not exist!";        return 0;    }    Return (M_INOTIFYFD! = lhfsmc_fd_uncreated_state)? Inotify_add_watch (M_INOTIFYFD, Filelocation, LHFSMC_MONITOR_ EVENT):-1);}

Summary:

The above is the Windows and Linux file Monitoring system implementation of the relevant ideas and code, just as a introduction, the use of this method can achieve the corresponding function.

"Big talk qt Five" implementation of file operation monitoring under Windows and Linux