I’ve been working for years in Xojo 2015 Release 1 and am now trying out 2017 Release 3. I’ve always stored my projects on an OS X file server and had no trouble. This way I can access the project from my desktop or laptop. But now I can’t compile on my server. It works fine on my local hard drive, but on my server, when I try to compile a .debug version, I get:
Compilation of “[My Application]” failed.
A file system error occurred (#103) for ““Resources””. If the application already exists, please make sure it is not currently running; otherwise, please make sure that the destination directory is writable.
The compiler does create a .debug file of the normal size and I noticed the package contents includes a Frameworks folder with a Resources alias that wasn’t there in earlier compiles. In fact, when I compile on my local drive, the .debug program is 8 times as big (2.4mb–>16.6mb) as when compiled with 2015 Release 1.
I can switch back to 2015 Release 1 and have no problem. I’ve searched extensively for others with this problem and am surprised that I haven’t found anything. Someone else must be using a file server. Any help would be appreciated.
Could this simply be related to the topic discussed many times earlier?
Where the “debug” file is not properly deleted by the OS? and therefore causing a subseqent compile to fail?
I’ve even tried storing the project file on my wife’s shared computer and had the same problem. It should be easy for anyone to confirm the problem with an other computer on your LAN. It seems like a permissions problem.
What happens all too often is that remote storage locks the file to prevent modification during transfer. It interferes with Xojo trying to delete the debug executable too early for the taste of the network.
At one point, there was also a bug in Xojo web where the debug build never went away, even local.
[quote=376452:@Emile Schwarz]So, if a bug is documented, and a work-around exists and the software owner do not want to squash it, do not talk about it ?
Strange, very strange.[/quote]
its a remote server access issue and not a Xojo issue per se. I run into this issue all the time with various Enterprise products from (name major vendors like Oracle, Microsoft, Apple, IBM, HPI/HPE, etc). As what has been mentioned many times on this forum, doing this type of work via a cloud drive, network share, etc will cause problems. it is how the cloud drive, network share, etc operate.
the only fix I can see Xojo putting in Xojo (IDE) is to check to see if the code is on a shared drive, network drive, cloud drive, and not allow you to save/build/etc to it. Which just opens a new can of worms to deal with.
Is it possible to tell Xojo to debug/build to local drive?
That way even if the project is on file server, shared/network/cloud drive, there will be less problems.
[quote=376530:@Alberto De Poo]Is it possible to tell Xojo to debug/build to local drive?
That way even if the project is on file server, shared/network/cloud drive, there will be less problems.[/quote]
that would be a question for @Xojo to answer but I believe the answer is no. Could that be changed in the IDE, maybe?
Thanks for the responses and suggestions. However, none of these comments addresses the fact that with previous versions of Xojo there was no problem working directly on my server. Does this suggestion that there was previously a bug in Xojo that allowed me to work this way and they’ve fixed it along the way?
This is not an iCloud drive or some other hosted server. It’s an OS X Server, arguable a very professional server. I maintain the server on my LAN. My wife and I do all of our work on this server, accessing documents from several computers, loading and saving from dozens of apps, none of which have this sort of problem.
I’m disappointed that the response here is that I should just suck it up and work around the problem that didn’t exist until I tried a later version of Xojo. I will continue to hope that someone else will reveal a professional solution that doesn’t involve changing my workflow. Thank you.
They’ve had to change the build process along the way to account for system changes. I don’t have specifics for you (I’m not staff I don’t know what they are,) but an example might be the changes that were done recently to get around issues with Apple’s new file system holding on to files.
Well, I would argue the professional solution would be to change your workflow. Source control repositories will keep all your devices in sync, maintain changes, and allow you to roll back should you ever need to. Source control is the professional solution.
I have both SMB and AFP (Apple File Protocol) shares on my LAN. I just discovered that the compile process only fails on SMB shares. I’ve been favoring SMB because it’s supposed to be faster and more versatile. But I still keep a couple of shares on AFP only. I tried moving my project folder there and compiling works as expected. I find this to be an acceptable workaround.
Tim, thanks for your input. For me, my server gives me easy access to my projects. I can close a project on my desktop and pick it up on my laptop without having to make duplicates and copy them (with the potential for confusing the latest version). This outweighs source control systems for me. I use my own system to manage versions, with occasional help from Time Machine. So I’ll retract my “professional solution” comment and do it my way. I guess old habits die hard. I’m currently rewriting MIDI software I wrote 25 years ago in 68000 assembly code on the Atari ST.
