Re: [Flightgear-devel] Bug 479 has come back
-Original Message- From: ThorstenB Sent: Thursday, November 15, 2012 7:09 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Bug 479 has come back Apparently the path checker somehow mismatches the given file path and the fg-aircraft path. This is obviously caused by the conversion of the path to an absolute path - but it's strange since absolute paths should certainly work (and they are what should normally be given on the command-line in the first place, so the conversion should not really have changed anything, except for those who were using relative paths - but those weren't even working before). We either need someone running Windows to debug this. Alternatively, please provide the exact values of the * fg-aircraft command-line parameter (--fg-aircraft=...) * The value of the /sim/fg-aircraft property (see property tree) * The exact path given in the error message (loadxml: reading '...' denied) Make sure to copy the paths exactly as shown - even tiny differences (such as / vs \, or an appended extra slash may make a difference). cheers, Thorsten -- Thortsen Here is my system.fgsrc file and then the log output.~ My TSR2, if you need it, is at g...@gitorious.org:fg-ajt/tsr2.git. The final Nasal error (nil used in numeric context) only occurs when I use the new version of simgear/misc/sg_path.cxx. Changing --fg-aircraft=C:\FlightGear\MyAircraft to --fg-aircraft=C:\FlightGear\MyAircraft\ , or to --fg-aircraft=C:/FlightGear/MyAircraft has no effect. In each case the property /sim/fg-aircraft is that specified by --fg-aircraft=, except that the trailing \ is discarded. I ran flightgear with the command: C:\FlightGear\install\msvc100\bin\fgfs.exe fgfsrun.txt 21 system.fgsrc:- --fg-root=C:/FlightGear/fgdata --fg-scenery=C:\FlightGear\MyScenery;C:\FlightGear\Terrasync;C:\FlightGear\flightgear --fg-aircraft=C:\FlightGear\MyAircraft --airport=EGNO --aircraft=TSR2 --control=joystick --enable-random-objects --enable-horizon-effect --enable-enhanced-lighting --enable-ai-models --enable-real-weather-fetch --enable-clouds3d --prop:/sim/frame-rate-throttle-hz=60 --prop:/sim/traffic-manager/enabled=0 --geometry=1024x768 --visibility-miles=30 --bpp=32 --log-level=alert --timeofday=noon --enable-rembrandt Log file: No GAIN specified (default: 1.0) loadxml: reading 'C:/FlightGear/MyAircraft/TSR2/Dialogs/config.xml' denied (unauthorized access) Nasal runtime error: Dialog class: XML dialog must have name at C:/FlightGear/fgdata/Nasal/gui.nas, line 354 called from: C:/FlightGear/fgdata/Nasal/gui.nas, line 334 called from: C:/FlightGear/fgdata/Nasal/globals.nas, line 100 Nasal runtime error: container index not scalar at C:/FlightGear/fgdata/Nasal/gui.nas, line 336 called from: C:/FlightGear/MyAircraft/TSR2/Nasal/TSR2-main.nas, line 26 Switches.nas Annunciator.nas controls.nas timers.nas electrical.nas Engine-Start-Stop.nas TSR2 undercarriage.nas settimer(gearLights, 0); navradiodisplay.nas g-meter.nas ice-warn.nas Init properties.nas startup.nas dropview.nas TSR2-moving-map.nas TSR2 autopilot.nas TSR2 contrail.nas TSR2 liveries.nas loadxml: reading 'C:/FlightGear/MyAircraft/TSR2/Models/Liveries/BlackTest.xml' denied (unauthorized access) Nasal runtime error: non-objects have no members at C:/FlightGear/fgdata/Nasal/gui.nas, line 479 called from: C:/FlightGear/fgdata/Nasal/gui.nas, line 460 called from: C:/FlightGear/fgdata/Nasal/gui.nas, line 450 called from: C:/FlightGear/fgdata/Nasal/aircraft.nas, line 519 called from: C:/FlightGear/MyAircraft/TSR2/Nasal/liveries.nas, line 4 dialogs.nas loadxml: reading 'C:/FlightGear/MyAircraft/TSR2/Dialogs/TSR2-autopilot-dlg.xml' denied (unauthorized access) Nasal runtime error: Dialog class: XML dialog must have name at C:/FlightGear/fgdata/Nasal/gui.nas, line 354 called from: C:/FlightGear/fgdata/Nasal/gui.nas, line 334 called from: C:/FlightGear/fgdata/Nasal/globals.nas, line 100 Nasal runtime error: container index not scalar at C:/FlightGear/fgdata/Nasal/gui.nas, line 336 called from: C:/FlightGear/MyAircraft/TSR2/Nasal/TSR2-dialogs.nas, line 7 TSR2 canvas HUD.nas loading scenario 'nimitz_demo' map init-props moving map loaded Nasal runtime error: nil used in numeric context at C:/FlightGear/MyAircraft/TSR2/Nasal/TSR2-canvas-HUD.nas, line 276 called from: C:/FlightGear/MyAircraft/TSR2/Nasal/TSR2-canvas-HUD.nas, line 354 called from: C:/FlightGear/fgdata/Nasal/globals.nas, line 100 Nasal runtime error: nil used in numeric context at C:/FlightGear/MyAircraft/TSR2/Nasal/TSR2-g-meter.nas, line 14 icewarn I hope that this helps debug the problem. Alan -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure
Re: [Flightgear-devel] Bug 479 has come back
Alan wrote: -Original Message- From: ThorstenB Sent: Thursday, November 15, 2012 7:09 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Bug 479 has come back Apparently the path checker somehow mismatches the given file path and the fg-aircraft path. This is obviously caused by the conversion of the path to an absolute path - but it's strange since absolute paths should certainly work (and they are what should normally be given on the command-line in the first place, so the conversion should not really have changed anything, except for those who were using relative paths - but those weren't even working before). We either need someone running Windows to debug this. Alternatively, please provide the exact values of the * fg-aircraft command-line parameter (--fg-aircraft=...) * The value of the /sim/fg-aircraft property (see property tree) * The exact path given in the error message (loadxml: reading '...' denied) Make sure to copy the paths exactly as shown - even tiny differences (such as / vs \, or an appended extra slash may make a difference). cheers, Thorsten -- Thortsen Here is my system.fgsrc file and then the log output.~ My TSR2, if you need it, is at g...@gitorious.org:fg-ajt/tsr2.git. The final Nasal error (nil used in numeric context) only occurs when I use the new version of simgear/misc/sg_path.cxx. Changing --fg-aircraft=C:\FlightGear\MyAircraft to --fg-aircraft=C:\FlightGear\MyAircraft\ , or to --fg-aircraft=C:/FlightGear/MyAircraft has no effect. In each case the property /sim/fg-aircraft is that specified by --fg-aircraft=, except that the trailing \ is discarded. I ran flightgear with the command: C:\FlightGear\install\msvc100\bin\fgfs.exe fgfsrun.txt 21 system.fgsrc:- --fg-root=C:/FlightGear/fgdata --fg- scenery=C:\FlightGear\MyScenery;C:\FlightGear\Terrasync;C:\FlightGear\fli ghtgear --fg-aircraft=C:\FlightGear\MyAircraft --airport=EGNO --aircraft=TSR2 --control=joystick --enable-random-objects --enable-horizon-effect --enable-enhanced-lighting --enable-ai-models --enable-real-weather-fetch --enable-clouds3d --prop:/sim/frame-rate-throttle-hz=60 --prop:/sim/traffic-manager/enabled=0 --geometry=1024x768 --visibility-miles=30 --bpp=32 --log-level=alert --timeofday=noon --enable-rembrandt Log file: No GAIN specified (default: 1.0) loadxml: reading 'C:/FlightGear/MyAircraft/TSR2/Dialogs/config.xml' denied (unauthorized access) Nasal runtime error: Dialog class: XML dialog must have name at C:/FlightGear/fgdata/Nasal/gui.nas, line 354 called from: C:/FlightGear/fgdata/Nasal/gui.nas, line 334 called from: C:/FlightGear/fgdata/Nasal/globals.nas, line 100 Nasal runtime error: container index not scalar at C:/FlightGear/fgdata/Nasal/gui.nas, line 336 called from: C:/FlightGear/MyAircraft/TSR2/Nasal/TSR2-main.nas, line 26 Switches.nas Annunciator.nas controls.nas timers.nas electrical.nas Engine-Start-Stop.nas TSR2 undercarriage.nas settimer(gearLights, 0); navradiodisplay.nas g-meter.nas ice-warn.nas Init properties.nas startup.nas dropview.nas TSR2-moving-map.nas TSR2 autopilot.nas TSR2 contrail.nas TSR2 liveries.nas loadxml: reading 'C:/FlightGear/MyAircraft/TSR2/Models/Liveries/BlackTest.xml' denied (unauthorized access) Nasal runtime error: non-objects have no members at C:/FlightGear/fgdata/Nasal/gui.nas, line 479 called from: C:/FlightGear/fgdata/Nasal/gui.nas, line 460 called from: C:/FlightGear/fgdata/Nasal/gui.nas, line 450 called from: C:/FlightGear/fgdata/Nasal/aircraft.nas, line 519 called from: C:/FlightGear/MyAircraft/TSR2/Nasal/liveries.nas, line 4 dialogs.nas loadxml: reading 'C:/FlightGear/MyAircraft/TSR2/Dialogs/TSR2-autopilot-dlg.xml' denied (unauthorized access) Nasal runtime error: Dialog class: XML dialog must have name at C:/FlightGear/fgdata/Nasal/gui.nas, line 354 called from: C:/FlightGear/fgdata/Nasal/gui.nas, line 334 called from: C:/FlightGear/fgdata/Nasal/globals.nas, line 100 Nasal runtime error: container index not scalar at C:/FlightGear/fgdata/Nasal/gui.nas, line 336 called from: C:/FlightGear/MyAircraft/TSR2/Nasal/TSR2-dialogs.nas, line 7 TSR2 canvas HUD.nas loading scenario 'nimitz_demo' map init-props moving map loaded Nasal runtime error: nil used in numeric context at C:/FlightGear/MyAircraft/TSR2/Nasal/TSR2-canvas-HUD.nas, line 276 called from: C:/FlightGear/MyAircraft/TSR2/Nasal/TSR2-canvas-HUD.nas, line 354 called from: C:/FlightGear/fgdata/Nasal/globals.nas, line 100 Nasal runtime error: nil used in numeric context at C:/FlightGear/MyAircraft/TSR2/Nasal/TSR2-g-meter.nas, line 14 icewarn I hope that this helps debug the problem. I was going to check on my version of FG/SG pulled today with MCVC10 but it failed with: 29d:\git_new
Re: [Flightgear-devel] Bug 479 has come back
Am 2012-11-16 14:39, schrieb Vivian Meazza: It has also failed to build in Jenkins with the same error. When someone gets around to fixing it I'll try to test again. Just as an aside, would it be possible to test for developers to test their inputs BEFORE they get pushed into Gitorious? I always test my code before pushing anything to gitorious. The problem is that I have not always access to a computer running Windows and Visual Studio so sometimes I have just to rely on the output of Jenkins. Especially the last commits made heavy use of templates where VS seems to be very buggy. If something doesn't work I normally fix it within a few hours, so sorry for any inconveniences if you happen to checkout before I've been able to push a fix. Tom -- Thomas Geymayer www.tomprogs.at / C-Forum und Tutorial: www.proggen.org Student of Computer Science @ Graz University of Technology --- Austria -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug 479 has come back
Am 16.11.2012 10:13, schrieb Alan Teeder:
Changing --fg-aircraft=C:\FlightGear\MyAircraft
to --fg-aircraft=C:\FlightGear\MyAircraft\ ,
or to --fg-aircraft=C:/FlightGear/MyAircraft has no effect.
Pull latest fgdata and see if it has any effect.
Is it possible that things were only working before, when the path given
for --fg-aircraft used / instead of the usual Windows \ path
separator? There was something goofed up in Nasal/io.nas, which suggests
this should have been the case.
If it's still not working, replace your fgdata/Nasal/io.nas with the
attached version, run fgfs, reproduce the issue and send the log output
to me (default log settings are enough).
cheers,
Thorsten
# Reads and returns a complete file as a string
var readfile = func(file) {
if ((var st = stat(file)) == nil)
die(Cannot stat file: ~ file);
var sz = st[7];
var buf = bits.buf(sz);
read(open(file), buf, sz);
return buf;
}
# Loads Nasal file into namespace and executes it. The namespace
# (module name) is taken from the optional second argument, or
# derived from the Nasal file's name.
#
# Usage: io.load_nasal(filename [, modulename]);
#
# Example:
#
# io.load_nasal(getprop(/sim/fg-root) ~ /Local/test.nas);
# io.load_nasal(/tmp/foo.nas, test);
#
var load_nasal = func(file, module = nil) {
if (module == nil)
module = split(., split(/, file)[-1])[0];
printlog(info, loading , file, into namespace , module);
if (!contains(globals, module))
globals[module] = {};
elsif (typeof(globals[module]) != hash)
die(io.load_nasal(): namespace ' ~ module ~ ' already in use, but
not a hash);
var code = call(func compile(readfile(file), file), nil, var err = []);
if (size(err)) {
(func nil)(); # FIXME hack around
Nasal bug
if (substr(err[0], 0, 12) == Parse error:) { # hack around Nasal
feature
var e = split( at line , err[0]);
if (size(e) == 2)
err[0] = string.join(, [e[0], \n at , file, , line ,
e[1], \n ]);
}
for (var i = 1; (var c = caller(i)) != nil; i += 1)
err ~= subvec(c, 2, 2);
debug.printerror(err);
return 0;
}
call(bind(code, globals), nil, nil, globals[module], err);
debug.printerror(err);
return !size(err);
}
# Load XML file in FlightGear's native PropertyList format.
# If the second, optional target parameter is set, then the properties
# are loaded to this node in the global property tree. Otherwise they
# are returned as a separate props.Node tree. Returns the data as a
# props.Node on success or nil on error.
#
# Usage: io.read_properties(filename [, props.Node or property-path]);
#
# Examples:
#
# var target = props.globals.getNode(/sim/model);
# io.read_properties(/tmp/foo.xml, target);
#
# var data = io.read_properties(/tmp/foo.xml, /sim/model);
# var data = io.read_properties(/tmp/foo.xml);
#
var read_properties = func(path, target = nil) {
var args = props.Node.new({ filename: path });
if (target == nil) {
var ret = args.getNode(data, 1);
} elsif (isa(target, props.Node)) {
args.getNode(targetnode, 1).setValue(target.getPath());
var ret = target;
} else {
args.getNode(targetnode, 1).setValue(target);
var ret = props.globals.getNode(target, 1);
}
return fgcommand(loadxml, args) ? ret : nil;
}
# Load XML file in FlightGear's native PropertyList format.
# file will be located in the airport-scenery directories according to
# ICAO and filename, i,e in Airports/I/C/A/ICAO.filename.xml
# If the second, optional target parameter is set, then the properties
# are loaded to this node in the global property tree. Otherwise they
# are returned as a separate props.Node tree. Returns the data as a
# props.Node on success or nil on error.
#
# Usage: io.read_airport_properties(icao, filename [, props.Node or
property-path]);
#
# Examples:
#
# var data = io.read_properties(KSFO, rwyuse);
#
var read_airport_properties = func(icao, fname, target = nil) {
var args = props.Node.new({ filename: fname, icao:icao });
if (target == nil) {
var ret = args.getNode(data, 1);
} elsif (isa(target, props.Node)) {
args.getNode(targetnode, 1).setValue(target.getPath());
var ret = target;
} else {
args.getNode(targetnode, 1).setValue(target);
var ret = props.globals.getNode(target, 1);
}
return fgcommand(loadxml, args) ? ret : nil;
}
# Write XML file in FlightGear's native PropertyList format.
# Returns the filename on success or nil on error. If the source
# is a props.Node that refers to a node in the main tree, then
# the data are directly written from the tree, yielding a more
# accurate result. Otherwise the data need to be copied first,
# which may slightly change node types (FLOAT becomes DOUBLE etc.)
#
# Usage: io.write_properties(filename,
Re: [Flightgear-devel] Bug 479 has come back
-Original Message- From: ThorstenB Sent: Friday, November 16, 2012 8:18 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Bug 479 has come back Am 16.11.2012 10:13, schrieb Alan Teeder: Changing --fg-aircraft=C:\FlightGear\MyAircraft to --fg-aircraft=C:\FlightGear\MyAircraft\ , or to --fg-aircraft=C:/FlightGear/MyAircraft has no effect. Pull latest fgdata and see if it has any effect. Is it possible that things were only working before, when the path given for --fg-aircraft used / instead of the usual Windows \ path separator? There was something goofed up in Nasal/io.nas, which suggests this should have been the case. If it's still not working, replace your fgdata/Nasal/io.nas with the attached version, run fgfs, reproduce the issue and send the log output to me (default log settings are enough). cheers, Thorsten Thorsten It all works out of the (git) box now. I have not tried the io.nas that you attached to your post, but can do if you wish. Thanks Alan -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug 479 has come back
Am 16.11.2012 22:28, schrieb Alan Teeder: It all works out of the (git) box now. I have not tried the io.nas that you attached to your post, but can do if you wish. No need to, if it's working now. I believe we've fixed another old and ugly bug here, requiring Windows users to use Unix-style paths for some command-line parameters to make Nasal access work (namely for --fg-aircraft and --fg-scenery). The realpath patch only extended the existing issue - since realpath converts Unix-style paths back to proper Windows-style paths - so now the issue also caught those using Unix-style paths as a work-around so far. Thanks, Thorsten -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug 479 has come back
Tom wrote: -Original Message- From: Thomas Geymayer [mailto:tom...@gmail.com] Sent: 16 November 2012 15:07 To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] Bug 479 has come back Am 2012-11-16 14:39, schrieb Vivian Meazza: It has also failed to build in Jenkins with the same error. When someone gets around to fixing it I'll try to test again. Just as an aside, would it be possible to test for developers to test their inputs BEFORE they get pushed into Gitorious? I always test my code before pushing anything to gitorious. The problem is that I have not always access to a computer running Windows and Visual Studio so sometimes I have just to rely on the output of Jenkins. Especially the last commits made heavy use of templates where VS seems to be very buggy. If something doesn't work I normally fix it within a few hours, so sorry for any inconveniences if you happen to checkout before I've been able to push a fix. Tom Always happy to help with testing - although probably not fixing work-arounds for MSVC10 shortcomings. All built here now - and all seems to be working as it should with my models anyway - is there any particular aircraft which is causing problems? Vivian -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug 479 has come back
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/16/2012 11:48 PM, Vivian Meazza wrote: Always happy to help with testing - although probably not fixing work-arounds for MSVC10 shortcomings. All built here now - and all seems to be working as it should with my models anyway - is there any particular aircraft which is causing problems? Vivian Some revisions ago, the A380 was fine, now some buttons in overhead panel are incorrectly shown. Roland -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlCmw0kACgkQty+BhcbHvXjCnACfWJeosrhR4FFboHybJdN9vf1I PeMAoLEb4jt+Si4+ZE+CQPrPjVyoClsj =MUCZ -END PGP SIGNATURE- -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug 479 has come back
-Original Message- From: Vivian Meazza Sent: Friday, November 16, 2012 10:48 PM To: 'FlightGear developers discussions' Subject: Re: [Flightgear-devel] Bug 479 has come back Always happy to help with testing - although probably not fixing work-arounds for MSVC10 shortcomings. All built here now - and all seems to be working as it should with my models anyway - is there any particular aircraft which is causing problems? Vivian Vivian This only affected aircraft outside the fgdata/aircraft path e.g. /fgdata/myaircraft/foobird. Even then (AFAIK) it only affected dialogues and livery schemes on windows boxes, so it would not have been apparent to many users/developers. It did get me on all of those counts ;-( Alan -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug 479 has come back
All is OK when I reset git to 10 October. From: Alan Teeder Sent: Thursday, November 15, 2012 11:32 AM To: Flightgear-devel@lists.sourceforge.net Subject: [Flightgear-devel] Bug 479 has come back Bug 479 (loadxml: reading 'file.xml' denied (unauthorized access) from --aircraft directory) has come back during the last week. (Windows MSVC 2010). If I revert Simgear and Flightgear to 7 October all is well. I have not yet had time to find which commit is causing the problem. Alan .-- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug 479 has come back
Found it ! Here is the culprit: commit dbea0c936103b2530e551be7c51bc6bd7b5218cb Author: ThorstenB Date: Sun Nov 11 19:26:51 2012 +0100 Geoff McLane: realpath for Windows using _fullpath. Alan From: Alan Teeder Sent: Thursday, November 15, 2012 11:32 AM To: Flightgear-devel@lists.sourceforge.net Subject: [Flightgear-devel] Bug 479 has come back Bug 479 (loadxml: reading 'file.xml' denied (unauthorized access) from --aircraft directory) has come back during the last week. (Windows MSVC 2010). If I revert Simgear and Flightgear to 7 October all is well. I have not yet had time to find which commit is causing the problem. Alan -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug 479 has come back
Well it did work until commit fe1222a90dd809560e787ce09391d5cf97bbe6fe Author: Thomas Geymayer Date: Thu Nov 15 11:55:25 2012 +0100 Optional profiling commands using gperftools See Jon Stockill´s post in the commitlogs list. From: Alan Teeder Sent: Thursday, November 15, 2012 11:55 AM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Bug 479 has come back Found it ! Here is the culprit: commit dbea0c936103b2530e551be7c51bc6bd7b5218cb Author: ThorstenB Date: Sun Nov 11 19:26:51 2012 +0100 Geoff McLane: realpath for Windows using _fullpath. Alan From: Alan Teeder Sent: Thursday, November 15, 2012 11:32 AM To: Flightgear-devel@lists.sourceforge.net Subject: [Flightgear-devel] Bug 479 has come back Bug 479 (loadxml: reading 'file.xml' denied (unauthorized access) from --aircraft directory) has come back during the last week. (Windows MSVC 2010). If I revert Simgear and Flightgear to 7 October all is well. I have not yet had time to find which commit is causing the problem. Alan -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug 479 has come back
Am 15.11.2012 12:55, schrieb Alan Teeder: Found it ! Here is the culprit: commit dbea0c936103b2530e551be7c51bc6bd7b5218cb Author: ThorstenB Date: Sun Nov 11 19:26:51 2012 +0100 Geoff McLane: realpath for Windows using _fullpath. Alan *From:* Alan Teeder mailto:ajtee...@v-twin.org.uk *Sent:* Thursday, November 15, 2012 11:32 AM *To:* Flightgear-devel@lists.sourceforge.net mailto:Flightgear-devel@lists.sourceforge.net *Subject:* [Flightgear-devel] Bug 479 has come back Bug 479 (loadxml: reading 'file.xml' denied (unauthorized access) from --aircraft directory) has come back during the last week. (Windows MSVC 2010). Apparently the path checker somehow mismatches the given file path and the fg-aircraft path. This is obviously caused by the conversion of the path to an absolute path - but it's strange since absolute paths should certainly work (and they are what should normally be given on the command-line in the first place, so the conversion should not really have changed anything, except for those who were using relative paths - but those weren't even working before). We either need someone running Windows to debug this. Alternatively, please provide the exact values of the * fg-aircraft command-line parameter (--fg-aircraft=...) * The value of the /sim/fg-aircraft property (see property tree) * The exact path given in the error message (loadxml: reading '...' denied) Make sure to copy the paths exactly as shown - even tiny differences (such as / vs \, or an appended extra slash may make a difference). cheers, Thorsten -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
