User forums > Using Code::Blocks

Network drive problem

(1/3) > >>

Kylotan:
Maybe this is related to http://forums.codeblocks.org/index.php/topic,1332.0.html, I don't know. Basically, I can't use Code::Blocks on a network drive. The project file and all files are in \\server\dir_a\dir_b, but after they're added to the project, they can't be opened from within Code::Blocks as it thinks that they are located at \\server\server\dir_a\dir_b . Somehow the server name seems to get added as a directory name. And instead of storing the files in the project file as "filename.c", they get stored as "..\..\server\dir_a\dir_b\filename.c".

Note that it finds them ok when 'Add Files Recursively' is used, displaying them in the list box. It's only after they get added to the project that the problem has arisen.

MortenMacFly:

--- Quote from: Kylotan on November 10, 2005, 03:06:44 pm ---Basically, I can't use Code::Blocks on a network drive.

--- End quote ---
Whoohoo... I wonder whether it's a good idea at all to develop on a network drive. Imagine the server disconnects during development - a lot of work maybe lost. Furthermore there should normally be performance issues as well...

However, you may get around this issue by assigning a drive letter to the network share (if it's Windows).

But: Basically I really don't know whether it's worth supporting it?! Other software (e.g. WinCVS) goes a step further - it issues an error then.

Morten.

Kylotan:

--- Quote from: MortenMacFly on November 10, 2005, 03:18:00 pm ---Whoohoo... I wonder whether it's a good idea at all to develop on a network drive. Imagine the server disconnects during development - a lot of work maybe lost. Furthermore there should normally be performance issues as well...
--- End quote ---

The whole world is networked these days. If the server disconnects, then I just wait until it is available again. In this situation, Code::Blocks could choose to save a temporary file locally if it wanted, for safety purposes. As for performance, I don't think that 10Mbits/second is too slow to save a source code file!


--- Quote ---However, you may get around this issue by assigning a drive letter to the network share (if it's Windows).
--- End quote ---

Unfortunately that's not practical due to the setup I have to work with. But I think it's important that the developers here see that this problem exists, which might actually be easy to fix.

thomas:

--- Quote from: Kylotan on November 10, 2005, 03:30:49 pm ---Unfortunately that's not practical due to the setup I have to work with.
--- End quote ---
Actually that's the easiest thing of the world. I work with it like that every day, it's a snap to set up, and the program does not even know it is not working on a real drive. Really, you should try that.


--- Quote from: Kylotan on November 10, 2005, 03:30:49 pm ---But I think it's important that the developers here see that this problem exists, which might actually be easy to fix.
--- End quote ---
The real problem is that the naming scheme\\server\some\dir is incompatible with everything in the world except Windows Explorer. It will be rather hard if not impossible to fix this.
In fact, this stupid Microsoft scheme is what prevents the application from using forward-slashes for all file locations, which would be a lot more compatible, more efficient, a lot easier to implement, and a lot less error prone. Many (if not all) of our filesystem related problems only arise because the Windows designers are too ignorant, too stupid or too lazy to support forward slashes in network folders (or any other scheme which is in any way compatible to anything, for that matter).
It is because of this that every path gets converted to and from different representations and re-normalized all the time, which consumes the major part of your CPU time.
Just to give you a figure about how expensive this really is:  While adding a file to a project, the path is mangled about a dozen times. A whole 35% of the total time needed to load a project goes into wxFileName::Normalize alone (and another 30% into other pathname mangling).
<End of MS rant>  :)

Kylotan:

--- Quote from: thomas on November 10, 2005, 04:51:21 pm ---Actually that's the easiest thing of the world. I work with it like that every day, it's a snap to set up, and the program does not even know it is not working on a real drive. Really, you should try that.
--- End quote ---

Perhaps I wasn't clear - it's not that I don't know how to map a network drive, it's that it's not an option in this case. For example, needing to do this from multiple computers where free drive letters may differ, or from computers where I don't have permission to do this.


--- Quote from: thomas on November 10, 2005, 04:51:21 pm ---The real problem is that the naming scheme\\server\some\dir is incompatible with everything in the world except Windows Explorer. It will be rather hard if not impossible to fix this.
In fact, this stupid Microsoft scheme is what prevents the application from using forward-slashes for all file locations, which would be a lot more compatible, more efficient, a lot easier to implement, and a lot less error prone. Many (if not all) of our filesystem related problems only arise because the Windows designers are too ignorant, too stupid or too lazy to support forward slashes in network folders (or any other scheme which is in any way compatible to anything, for that matter).
--- End quote ---

I appreciate that this is a platform compatibility issue, but if the difference is just one of forward slashes vs. backwards slashes then that sounds like a bug or shortcoming in wxFileName or the code that calls it. Python, a cross-platform language, copes fine when you pass a \\server\path pathname to its open() function, so it's obviously not impossible to work with.

Navigation

[0] Message Index

[#] Next page