Its not possible to share a whole drive in random cases

Bug #556853 reported by eMTee
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
DC++
Fix Released
High
Unassigned
StrongDC++
Fix Committed
Undecided
Unassigned

Bug Description

The problem hits 0.67x and is because the FileFindIter class does not like if the given path is a root folder of a drive. If it created by passing a <drive:>\ like (or any other invalid) format to the constructor then the DirData structure member functions' retrurning values are computed on random memory content. isHidden() returns mostly false but not always as many reported :)

The attached patch can solve the problem, and with a quick look to the non-win32 part of the FileFindIter class, I think it should not hurt the *nix side, either.

Revision history for this message
eMTee (realprogger) wrote :
eMTee (realprogger)
description: updated
Revision history for this message
Big Muscle (bigmuscle) wrote :

Check this in MSDN:

As stated previously, you cannot use a trailing backslash (\) in the lpFileName input string for FindFirstFile, therefore it may not be obvious how to search root directories. If you want to see files or get the attributes of a root directory, the following options would apply:
To examine files in a root directory, you can use "C:\*" and step through the directory by using FindNextFile.

Source: http://msdn.microsoft.com/en-us/library/aa364418(VS.85).aspx

Revision history for this message
eMTee (realprogger) wrote :

We don't use the FileFindIter to examining files here. We instantiate it because it has code ready for checking hidden status of a folder, and that's what we use it for here (because there's no such function in the File class).

Yes, other code in ShareManager which examining >files< for sharing uses the method mentioned above. I can't see any connection with your comment and the problem here.

Revision history for this message
Big Muscle (bigmuscle) wrote :

Ah sorry, my bad. I didn't copy whole text and the last sentence was the most important:

- To get the attributes of a root directory, use the GetFileAttributes function.

And using this function looks to me much more logical than using FindFirstFile for it.
Also, if DirData structure has been nulled in FileFindIter constructor, it wouldn't return random content.

Revision history for this message
eMTee (realprogger) wrote :

Do we need to know the hidden status of the root folder (in win32)? Can it be even set (I couldn't find any GUI or command line way to do so)?

Revision history for this message
Big Muscle (bigmuscle) wrote :

True, attribute of root folder can't be set. However, I still don't see attached patch correct. Since some variables are not initialized, their value can be completely random. And randomness can cause that the patch will work randomly. In other words, "ff != FileFindIter()" will work only if ff and FileFindIter has unitialized variables set to same value.

Revision history for this message
eMTee (realprogger) wrote :

FileFindIter.handle is initalized as INVALID_HANDLE_VALUE. If the FindFirstFile call fails it returns INVALID_HANDLE_VALUE.
!= operator is overloaded so it compares the two objects' handle member's variable. In the *nix part its the same logic... Any problem with this?

Revision history for this message
poy (poy) wrote :

the patch is fine please commit.

could probably remove the "else" but that's cosmetics. ;)

Big Muscle (bigmuscle)
Changed in strongdc:
status: New → Fix Committed
eMTee (realprogger)
Changed in dcplusplus:
status: Confirmed → Fix Committed
Revision history for this message
poy (poy) wrote :

Fixed in version 0.762.

Changed in dcplusplus:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Related questions

Remote bug watches

Bug watches keep track of this bug in other bug trackers.