1 Apr 2005 03:28
1 Apr 2005 06:13
Re: NSBundle -initWithPath: warning
Sheldon Gill <sheldon <at> westnet.net.au>
2005-04-01 04:13:57 GMT
2005-04-01 04:13:57 GMT
> No ... but I can easily see what the problem is ... '//Local/Library'
> looks like a windows UNC path where 'Local' is the host and 'Library' is
> the share and the actual file is unspecified ... ie it would be a
> relative path on windows.
Absolute path on windows.
> I've fixed NSString to know that it's an absolute path when running on
> unix.
IMHO this is a partial mis-diagnosis of the fault.
Consider the code:
----<begin code> ----
- (id) initWithPath: (NSString*)path
{
[super init];
if (!path || [path length] == 0)
{
NSLog( <at> "No path specified for bundle");
[self dealloc];
return nil;
}
if ([path isAbsolutePath] == NO)
{
NSLog( <at> "WARNING: NSBundle -initWithPath: requires absolute path
names!");
path = [[[NSFileManager defaultManager] currentDirectoryPath]
(Continue reading)
1 Apr 2005 05:55
Re: NSBundle -initWithPath: warning
Sheldon Gill <sheldon <at> westnet.net.au>
2005-04-01 03:55:35 GMT
2005-04-01 03:55:35 GMT
David Ayers wrote: > Richard Frith-Macdonald wrote: > >> On 2005-03-31 09:25:17 +0100 David Ayers <d.ayers <at> inode.at> wrote: >> >>> Richard Frith-Macdonald wrote: >>> [snip] >>> >>>> >>>> No ... but I can easily see what the problem is ... >>>> '//Local/Library' looks like a windows UNC path where 'Local' is the >>>> host and 'Library' is the share and the actual file is unspecified >>>> ... ie it would be a relative path on windows. Absolute path, actually. >>> Are you sure this is the behavior we want? My opinion is in another thread... >>> The UNC path seems like an absolute path to me, comparable to '/' >> >> No ... I'm not sure ... I'm not a windows user. >> I have been treating a UNC path of the form '//host/share' like a >> drive-relative path of the form 'C:' and assuming that it should be >> considered 'relative' because it specifies a dvice but not as >> particular location on the device. I'm pretty convinced that 'C:' or >> 'C:file' are relative paths and 'C:/' and 'C:/file' are absolute. Yes, "C:file" is relative. "C:\file" is absolute. If you think of it as(Continue reading)
1 Apr 2005 11:19
Re: GSDragView wrong position
Richard Frith-Macdonald <richard <at> brainstorm.co.uk>
2005-04-01 09:19:37 GMT
2005-04-01 09:19:37 GMT
On 2005-04-01 02:28:52 +0100 Enrico Sersale <enrico <at> dtedu.net> wrote: > > Visible in GWorkspace and GNUMail. (Probably in other places too, but here > it's 4 am and I can't verify now). GNUMail runs natively on OS X so I must > suppose that this is a bug. I hope you are more awake now ... please could I have more information. I've recently fixed several bugs in DnD and was hoping I had it working pretty much fully as documented at last (I guess that may not be the same thing as working exactly like MacOS-X ... but I hope it is). However, until now the mouse offset argument when starting a DnD session has been ignored completely, and as there is no experience using it, I'm not sure I've got it right ... but that's one possible place to look for changes in behavior. Anyway ... If you could give me exact descriptions of where this appears wrong (and ideally the CVS version and the point in the GWorkspace/GNUMail source code that the DnD is initiated) I can make more of an attempt at understanding iwhat the issue might be. I've looked at GWorkspace and dragging icons on the shelf. The DnD here appears to be initiated in [FSNIcon(DraggingSource) startExternalDragOnEvent:] and this code appears to say that the bottom left corner of the image should be positioned at the current mouse location. Looking at it on my system, the visible icon image actually appears a few pixels above and to the right of the the mouse pointer ... if the image has a transparent border it could explain that small offset, if not ... I guess there is a bug there. Is that the problem you are referring to?
1 Apr 2005 11:12
Re: NSBundle -initWithPath: warning
David Ayers <d.ayers <at> inode.at>
2005-04-01 09:12:43 GMT
2005-04-01 09:12:43 GMT
Sheldon Gill wrote: > David Ayers wrote: > >>> No ... I'm not sure ... I'm not a windows user. >>> I have been treating a UNC path of the form '//host/share' like a >>> drive-relative path of the form 'C:' and assuming that it should be >>> considered 'relative' because it specifies a dvice but not as >>> particular location on the device. I'm pretty convinced that 'C:' or >>> 'C:file' are relative paths and 'C:/' and 'C:/file' are absolute. > > > Yes, "C:file" is relative. "C:\file" is absolute. If you think of it as > a forest of directory trees and the drive specifying which tree you're > talking about it makes a lot more sense. If you parse out the "C:" you > get "file" and "/file". Very interesting, indeed. I just tried another experiment: C: cd C:\TEMP D: mkdir C:Test and indeed, it did create C:\TEMP\Test > You can't change directories to a UNC path. You've got to mount it as a > local drive, first: 'net use x: \\host\share' Oh, I was aware of how to create a drive, I was just trying to explore the semantics of UNC paths. > UNC paths are handled by the file system layer but the DIR command is(Continue reading)
1 Apr 2005 11:30
Re: NSBundle -initWithPath: warning
David Ayers <d.ayers <at> inode.at>
2005-04-01 09:30:26 GMT
2005-04-01 09:30:26 GMT
Sheldon Gill wrote:
>
> Why is the code checking for an absolute path? It is superfluous and is
> more likely to cause problems than solve them.
I kind of agree that this seems superfluous. If there is a reason, we
need some documentation.
> Later on, it checks that the bundle directory is readable. Why?
This may have a reason wrt to setuid programs. A file may be detected
as non readable/writable because the real uid's don't match but actually
is readable/writable because the actual access is done with the
effective uid.
I'm not 100% sure about this behavior and whether we should be checking
or not. I've had warnings that defaults couldn't be created because of
this, even though they could have. But I'm not clear about the
intention of this feature within GNUstep in relation to access()
...
#include <unistd.h>
int access(const char *pathname, int mode);
...
The check is done with the process's real uid and gid,
rather than with the effective ids as is done when actuÂ
ally attempting an operation. This is to allow set-UID
programs to easily determine the invoking user's authorÂ
(Continue reading)
1 Apr 2005 12:30
Re: NSBundle -initWithPath: warning
Richard Frith-Macdonald <richard <at> brainstorm.co.uk>
2005-04-01 10:30:12 GMT
2005-04-01 10:30:12 GMT
On 2005-04-01 05:13:57 +0100 Sheldon Gill <sheldon <at> westnet.net.au> wrote:
>> No ... but I can easily see what the problem is ... '//Local/Library'
>> looks like a windows UNC path where 'Local' is the host and 'Library' is
>> the share and the actual file is unspecified ... ie it would be a
>> relative path on windows.
>
> Absolute path on windows.
So I gathered after much trawling of the web ... I've updated isAbsolute to
regard UNC style paths as absolute in all cases.
>> I've fixed NSString to know that it's an absolute path when running on
>> unix.
>
> IMHO this is a partial mis-diagnosis of the fault.
>
> Consider the code:
> ----<begin code> ----
>
> - (id) initWithPath: (NSString*)path
> {
> [super init];
>
> if (!path || [path length] == 0)
> {
> NSLog( <at> "No path specified for bundle");
> [self dealloc];
> return nil;
> }
(Continue reading)
1 Apr 2005 12:54
Re: NSBundle -initWithPath: warning
Richard Frith-Macdonald <richard <at> brainstorm.co.uk>
2005-04-01 10:54:20 GMT
2005-04-01 10:54:20 GMT
On 2005-04-01 10:12:43 +0100 David Ayers <d.ayers <at> inode.at> wrote: > We could definitely use some some precise documentation of the relevant > issues here in regard to what our path handling behavior should be. Yes ... please could windows users investigate the work I've done in CVS and let us know how well it corresponds to actual windows behavior. I'm completely unfamiliar with UNC paths and haven't been able to find anything which looks like a *definitive* reference to their behavior on the web. One person told me that '/' and '\' are completely interchangable on windows, so I coded to allow either in all places. Yet Alex Perez's last mail on this list seems to imply that ONLY '\\host\share' is valid for a UNC path. I've seen '\\host\share/directory/file' quoted on the web, but don't recall seeing '//host/share/directory/file' ... so if '//host/share' is NOT a UNC path, the current code should be ammended slightly. There are probably other such issues that I'm not even aware of. > I mean, are we/should we be tracking the "current directory per drive"? > What does it mean to -changeCurrentDirectoryPath: > - in the simple case where the drives match (this seems trivial) > - when the drives don't match? > > .... so that subsequent [obj writeToFile: <at> "D:file" atomically: YES] will > "do > the right thing"? I'm inclined to think that we should just expect the windows SetCurrentDirectory() call to do what it wants with the path it is given.(Continue reading)
1 Apr 2005 13:19
Re: NSBundle -initWithPath: warning
Richard Frith-Macdonald <richard <at> brainstorm.co.uk>
2005-04-01 11:19:35 GMT
2005-04-01 11:19:35 GMT
On 2005-04-01 10:30:26 +0100 David Ayers <d.ayers <at> inode.at> wrote: > Sheldon Gill wrote: > >> >> Why is the code checking for an absolute path? It is superfluous and is >> more likely to cause problems than solve them. > > I kind of agree that this seems superfluous. If there is a reason, we need > some documentation. The check is not superfluous ... and is already documented both in the Apple documentation and in the GNUstep base documentation. However, the behavior as a result of the check is undocumented ... though it should be of course. Reading the documentation conservatively/literally I think that the code should return nil as a result of the check ... however GNUstep has a history of being permissive, and the current automatic conversion from relative to absolute path might be considered a good thing. Certainly we should not be stricter is MacOS-X is not. I will test the behavior on MacOS-X and make the GNUstep behavior strict if MacOS-X is strict. >> Later on, it checks that the bundle directory is readable. Why? > > This may have a reason wrt to setuid programs. I think that's a digression onto another topic ... the Apple documentation specifically states that the method will return nil if the directory is not accessible and the GNUstep documentation says it will return nil if the directory doesn't exist. The code here is necessary to conform to spec, regardless of whatever merits it may or may not have. A file may be detected as non > readable/writable because the real uid's don't match but actually is(Continue reading)
1 Apr 2005 12:47
Re: NSBundle -initWithPath: warning
David Ayers <d.ayers <at> inode.at>
2005-04-01 10:47:11 GMT
2005-04-01 10:47:11 GMT
Richard Frith-Macdonald wrote: > On 2005-04-01 10:30:26 +0100 David Ayers <d.ayers <at> inode.at> wrote: > > >> Sheldon Gill wrote: >> >> >>> Why is the code checking for an absolute path? It is superfluous >>> and is more likely to cause problems than solve them. >> >> I kind of agree that this seems superfluous. If there is a reason, >> we need some documentation. > > > The check is not superfluous ... and is already documented both in > the Apple documentation and in the GNUstep base documentation. My bad! Indeed, now I recall it, but I should have checked again before replying anyway. > However, the behavior as a result of the check is undocumented ... > though it should be of course. Reading the documentation > conservatively/literally I think that the code should return nil as a > result of the check ... however GNUstep has a history of being > permissive, and the current automatic conversion from relative to > absolute path might be considered a good thing. Certainly we should > not be stricter is MacOS-X is not. I will test the behavior on > MacOS-X and make the GNUstep behavior strict if MacOS-X is strict. >(Continue reading)
RSS Feed