** Tags added: core
--
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/653295
Title:
Support Win32 Symbolic Links when indexing share
Status in DC++:
Confirmed
Bug description:
I want to share a
Probably its an acceptable solution, you can find info on some websites
describing this techinque as a possible solution (without any actual
implementation though). If you can come up with a complete tested patch
that integrate this to FileFindIter class and ShareManager::buildTree,
that'd possibly
Directory symbolic link already work fine so I will leave those alone.
Not tested hardlinks or junctions, but I think they should work.
I came up with a solution (not fully tested yet). Its not a very clean
solution, since it basically exploits the fact that CreateFile will resolve the
reprase
After your report I tried to check what'd need to follow symlinks, it'd need
modifications in the FileFindIter class in dcpp/File.cpp and in the
ShareManager::buildTree function. There are clear examples in the net about how
to detect a symlink but it wasn't clear to me how to follow them (getti
hmm, ok, perhaps not 100% transparent, always done what i expected
before though...guess the library i used at the time did something for
me I didn't know about.
So Im guessing then it just needs code adding to handle them in
whichever bit of code makes the "list" of files to hash/index?
I could
The answer is probably in the next page of your linked document
(http://msdn.microsoft.com/en-us/library/aa365682%28v=VS.85%29.aspx).
What behaviour is written there for FindFirstFile, FindFirstFileEx,
FindNextFile and the WIN32_FIND_DATA structure pointing to symlinks says the
opposite than you
6 matches
Mail list logo
