Author Topic: Network drive problem  (Read 10738 times)

Offline Kylotan

  • Multiple posting newcomer
  • *
  • Posts: 17
    • Free game development libraries
Network drive problem
« on: November 10, 2005, 03:06:44 pm »
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.

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: Network drive problem
« Reply #1 on: November 10, 2005, 03:18:00 pm »
Basically, I can't use Code::Blocks on a network drive.
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.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline Kylotan

  • Multiple posting newcomer
  • *
  • Posts: 17
    • Free game development libraries
Re: Network drive problem
« Reply #2 on: November 10, 2005, 03:30:49 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...

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).

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.

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Network drive problem
« Reply #3 on: November 10, 2005, 04:51:21 pm »
Unfortunately that's not practical due to the setup I have to work with.
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.

But I think it's important that the developers here see that this problem exists, which might actually be easy to fix.
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>  :)
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline Kylotan

  • Multiple posting newcomer
  • *
  • Posts: 17
    • Free game development libraries
Re: Network drive problem
« Reply #4 on: November 10, 2005, 05:08:50 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.

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.

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).

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.

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Network drive problem
« Reply #5 on: November 10, 2005, 05:26:32 pm »
that sounds like a bug or shortcoming in wxFileName or the code that calls it
Little one can do about that, though... unluckily, except writing a MyBetterFileName class, and recoding an awful lot in the application.

Oh, forgot to mention... Windows actually does support slashes in network folders. But it absolutely must have "\\" at the beginning, which is so darn stupid.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
Re: Network drive problem
« Reply #6 on: November 10, 2005, 06:05:34 pm »
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.

I know I'm in no place to suggest this, but have you considered using CVS so that you only have to change the source on ONE computer and the rest will be updated from CVS? IMO that's a much safer approach.

A warning: Codeblocks saves files by OVERWRITING them. It does NOT create new files and then rename them, which would be much safer in a network environment.

Let's suppose you manage to get the files-on-network-drive approach working. If something happens to the network connection when you're saving a file, you can kiss your file goodbye.

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: Network drive problem
« Reply #7 on: November 10, 2005, 06:26:23 pm »
Quote
A warning: Codeblocks saves files by OVERWRITING them. It does NOT create new files and then rename them, which would be much safer in a network environment.

What are you talking about? It saves to a temporary file first and if it succeeds then it overwrites the original file :shock:
Be patient!
This bug will be fixed soon...

Offline Kylotan

  • Multiple posting newcomer
  • *
  • Posts: 17
    • Free game development libraries
Re: Network drive problem
« Reply #8 on: November 10, 2005, 07:47:28 pm »
I know I'm in no place to suggest this, but have you considered using CVS so that you only have to change the source on ONE computer and the rest will be updated from CVS? IMO that's a much safer approach.

I know, but it's not practical here, and it doesn't solve the problem I mention. It would be good if Code::Blocks had CVS support though. (Or if it does, for it to be more obvious!)

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
Re: Network drive problem
« Reply #9 on: November 10, 2005, 08:32:40 pm »
What are you talking about? It saves to a temporary file first and if it succeeds then it overwrites the original file :shock:

Ack! My memory! :oops: I've stayed out of C::B development for too long :oops:

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: Network drive problem
« Reply #10 on: November 10, 2005, 10:11:03 pm »
What are you talking about? It saves to a temporary file first and if it succeeds then it overwrites the original file :shock:

Ack! My memory! :oops: I've stayed out of C::B development for too long :oops:

Rick, I have to apologize. It's *my* memory :oops:
I had applied this patch at a time but it was removed when the unicode conversion was made, probably to come back with a workaround.
Well, it never came back...
I 'll fix it now.
Sorry for the confusion.
Be patient!
This bug will be fixed soon...

Offline Urxae

  • Regular
  • ***
  • Posts: 376
Re: Network drive problem
« Reply #11 on: November 10, 2005, 10:12:58 pm »
It would be good if Code::Blocks had CVS support though.

May I suggest this plugin? It's still in development, but it provides basic Subversion and CVS support. If you can choose, I really reccommend Subversion over CVS.
In order for the plugin to work you do need an installation of (Tortoise)SVN/(Tortoise)CVS for it to use.

Quote
(Or if it does, for it to be more obvious!)

It's even included in (the Windows binary distribution of) RC2, how much more obvious can you get? Well, I suppose if it were installed by default in the binary distribution (which it currently isn't) and a README-FOR-CVS-AND-SVN-SUPPORT (:D) file was inluded in the CVS repository with the URL to get it (or just a checkout of the latest stable version of the sources in the contrib directory) that might qualify, but not much more.
Note that (according to the C::B download page) the version in RC2 has a bug though: it may crash if you don't have Subversion installed.
« Last Edit: November 10, 2005, 10:17:49 pm by Urxae »

Offline Kylotan

  • Multiple posting newcomer
  • *
  • Posts: 17
    • Free game development libraries
Re: Network drive problem
« Reply #12 on: November 11, 2005, 02:59:39 pm »
May I suggest this plugin? It's still in development, but it provides basic Subversion and CVS support.
...
It's even included in (the Windows binary distribution of) RC2, how much more obvious can you get?
Interesting - I must have not seen that during installation. I'll give it a go when they let me near a CVS server here.