[mtfslinkext-changes] [ ntfslinkext-Feature Requests-1766488 ] Support for Distributed Link Trackin
Brought to you by:
miracle2k
|
From: SourceForge.net <no...@so...> - 2007-08-03 19:36:31
|
Feature Requests item #1766488, was opened at 2007-08-02 16:24 Message generated for change (Comment added) made by wellread1 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=821639&aid=1766488&group_id=161885 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 5 Private: No Submitted By: wellread1 (wellread1) Assigned to: Nobody/Anonymous (nobody) Summary: Support for Distributed Link Tracking Services Initial Comment: This is a very nice implementation of a sorely needed capability. I have noticed that a few move/rename operations get missed with the current methods of intercepting Move and Rename operations on target directories. Renaming a directory that is on the direct path of a target directory is not trapped. Moving a directory containing multiple target directories may generate many messages and can be problematic if other move errors occur. Would it be possible to support tracking of linked target directories using the Microsoft Distributed Link Tracking Service? ---------------------------------------------------------------------- >Comment By: wellread1 (wellread1) Date: 2007-08-03 12:36 Message: Logged In: YES user_id=1859371 Originator: YES It seems the Directory Link Service provides link tracking for shortcuts and OLE objects only. Nonetheless, I think one can make use of this service by creating shortcuts pointing to the source directory for each reparse point. If one names each shortcut after the GUID of the reparse point and keeps it in a protected directory, it should be possible to use the IShelllink::Resolve Method (which takes advantage of the Directory Link Service) to recover the path to the source for any broken reparse point. This procedure would add only 1kb (for each shortcut) of storage overhead for each reparse point. It should also be possible maintain sufficient independent data to rebuild the the shortcuts if they were inadvertently deleted, so the entire procedure could be fairly robust. ---------------------------------------------------------------------- Comment By: Michael Elsdoerfer (miracle2k) Date: 2007-08-03 04:12 Message: Logged In: YES user_id=755086 Originator: NO Thanks for the suggestion, I didn't know about the service so far. I'll try to find the time to investigate. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=821639&aid=1766488&group_id=161885 |