Create support for paths longer than 255 characters

Bug #238482 reported by Pietry
6
Affects Status Importance Assigned to Milestone
DC++
Confirmed
Wishlist
Unassigned

Bug Description

I'm getting this error on 2 files with long file-/pathnames (whole path is bigger than 255 characters). At least I think the length of the path causes the problem, as I still can can access those 2 files with other programs.
DC++ version: 0.699

Revision history for this message
Pietry (pietry) wrote :

Linked from question.

Changed in dcplusplus:
importance: Undecided → Wishlist
Revision history for this message
Jacek Sieka (arnetheduck) wrote :

Anyone willing to investigate where this happens?

Changed in dcplusplus:
status: New → Confirmed
Revision history for this message
James Collier (james-collier412) wrote :

Unfortunately this is a bug in Windows:
"Handling long path is hard. Win32 has a file name length limit of MAX_PATH (which is defined as 260). People are looking for ways to extend the limit, as the file system supports a file name up to 32767 characters long. Apparently this has huge AppCompat implication. As we can see from this example, current applications may already have difficulty handling file path within the MAX_PATH limit, let alone file name with 32767 characters long."
-- Junfeng Zhang (http://blogs.msdn.com/junfeng/archive/2006/02/20/535875.aspx) viewed 6 Mar, 2009;
Published Monday, February 20, 2006

I don't know if this is still an issue with Windows Vista.
What version of Windows are you using? What version of DC++ are you using?

P.S. Too much information is better than too little.

Changed in dcplusplus:
status: Confirmed → Incomplete
poy (poy)
Changed in dcplusplus:
status: Incomplete → Confirmed
Revision history for this message
cologic (cologic) wrote :

I'm using WINE, which is presenting other odd issues at the moment, so I can only guarantee this builds and runs for me.

At least two main risks:
1) Non-\\?\ paths automatically get / translated to \. \\?\-prefixed paths don't, apparently. DC++ might depend on this behavior.

2) Patching those two callsites might not suffice.

Revision history for this message
cologic (cologic) wrote :

It's been reported that, indeed, the patch previously does not work. I still cannot usefully test this, but I'll make one more attempt at simply a more thorough version of the above, addressing both points. It does translate / to \\ and it also wraps several more filepath-related Win32 API callsites in File.cpp and FileReader.cpp.

It still doesn't work on WINE 1.6.2; the test suite creates the following error console messages:
[----------] 1 test from testarchive
[ RUN ] testarchive.test_archive
U::gNP: test/data/out/gtest.h => \\?\test\data\out\gtest.h
U::gNP: test/data/ => \\?\test\data\
U::gNP: test/data/out/ => \\?\test\data\out\
U::gNP: test/data/out/gtest.h => \\?\test\data\out\gtest.h
F::F: test/data/out/gtest.h \\?\test\data\out\gtest.h
U::gNP: test/data/out/gtest.h => \\?\test\data\out\gtest.h
Thrown: FileException: Path not found.
test/testarchive.cpp:17: Failure
Failed
FileException: Path not found.
[ FAILED ] testarchive.test_archive (3 ms)
[----------] 1 test from testarchive (5 ms total)

U::gNP == Util::getNtPath and F::F is File::File. Removing the Util::getNtPath call from F::F does, in fact, allow the test suite to pass under WINE 1.6, but as far as I can tell, based on MSDN documentation, that filename translation is correct. Without the ability to test on my end, this is probably about as far as I can go.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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