Re: FYI: Bug in -getInfoForFile:application:type:
Re: FYI: Bug in -getInfoForFile:application:type:
- Subject: Re: FYI: Bug in -getInfoForFile:application:type:
- From: Lars Sonchocky-Helldorf <email@hidden>
- Date: Sat, 26 Jul 2003 15:51:40 +0200
Am Samstag, 26.07.03 um 05:54 Uhr schrieb James Quick:
On Friday, July 25, 2003, at 09:57 AM, Lars Sonchocky-Helldorf wrote:
This is the answer I got from my coworker also affected by this bug:
Anfang der weitergeleiteten E-Mail:
Von: Enrico Sersale <email@hidden>
Datum: Fr, 25. Jul 2003 12:14:24 Europe/Berlin
An: Lars Sonchocky-Helldorf <email@hidden>
Betreff: Re: Fwd: FYI: Bug in -getInfoForFile:application:type:
Antwort an: email@hidden
On 2003-07-25 01:55:24 +0300 Lars Sonchocky-Helldorf
<email@hidden> wrote:
This is an answer I got on email@hidden. What do you
think?
Anfang der weitergeleiteten E-Mail:
Von: James Quick <email@hidden>
Datum: Di, 22. Jul 2003 16:47:13 Europe/Berlin
An: Lars Sonchocky-Helldorf <email@hidden>
Betreff: Re: FYI: Bug in -getInfoForFile:application:type:
Lars, you have misinterpreted the intended use of that method.
The getInfoForFile:application:type method is intended to be used
at
a high level to identify what applications known to Finder may be
used to
open a filesystem object.
Here type is to be interpreted in the context of applications
which register
the types of files they can open.
No, this is not true. The most of the time I use
-getInfoForFile:application:type: to get the type, _not_ the
application. And I need exactly those constants, not a file
extension. Otherwise the method could simply be: - (NSString
*)applicationForFile:(NSString *)fullPath The types returned by
NSFileManager are not equivalent. There are situations in wich I
need to use *both* NSFileManager and NSWorkspace methods. Take a
look at this example:
- (BOOL)isPakageAtPath:(NSString *)path
{
NSString *defApp, *type;
BOOL isdir;
[ws getInfoForFile: path application: &defApp type: &type];
if (type == NSApplicationFileType) { // it is an application
return YES;
} else if (type == NSPlainFileType) { // NSPlainFileType can be a
plain file
// or a directory (a
bundle, for example)
if ((([fm fileExistsAtPath: path isDirectory: &isdir]) && isdir))
{
// if it is a directory, it represents a
bundle, a font, etc...
return YES;
} }
return NO;
}
You are confusing this with the Foundation Class NSFileManager
whose method deal in filesystem objects as defined by the POSIX
spec.
The method fileAttributesAtPath:traverseLink: returns a dictionary
describing
the file metadata (permissions, size, modification time, etc.)
this include the
underlying file type -> Plain File, Directory, Symbolic Link,
FIFO, etc.
So the behavior of NSWorkspace is correct. You just misunderstood
how it was
to be used. In the context of Finder, a plain directory, is an
application file,
i.e. a path which should be passed to the application "Finder"
when selected by
the user.
On Monday, July 21, 2003, at 09:57 PM, Lars Sonchocky-Helldorf
wrote:
The method -getInfoForFile:application:type: is not working as
documented. This is not a bug against the documentation, the
documented behavior is fine. The bug should be fixed in the >
sourcecode.
How to reproduce it:
2003-07-17 05:53:48.487 getInfoForFile_bug[1742] path:
'/private/var/log/system.log' is of type: 'log', application:
'/Applications/Utilities/Console.app' is used to open it
2003-07-17 05:53:48.501 getInfoForFile_bug[1742] type is not
equal to any NS*FileType
2003-07-17 05:53:48.516 getInfoForFile_bug[1742] path: '/usr/' is
of type: '', application:
'/System/Library/CoreServices/Finder.app' is used to open it
2003-07-17 05:53:48.529 getInfoForFile_bug[1742] type is equal to
NSPlainFileType
The most important thing to me is that I want to get
NXDirectoryFileType if I pass a directory to the message,
NXFilesystemFileType if I pass a path to a mounted volume and
NXShellCommandFileType if I pass the path of a shell command.
Right now those are all considered as plain file
(NSPlainFileType). I understand that currently for some reasons
(unknown to me) the extension of a file is returned as type. This
is o.k. for me as long the three types NXDirectoryFileType,
NXFilesystemFileType and NXFilesystemFileType get a special
treatment. I would not mind if there would be even more constants
for instance NXLogFileType for the .log extension.
I filed this as bug radar 3337483
If you are also affected by this bug (or will be affected in a
future project) please file this bug too to show the importance
of a fix for this.
greetings, Lars
I think you are relying things to work the way they did in the old
days.
If you mean the old days of OPENSTEP you are right but
Your problem is that Type and Creator codes are going away.
it seems you are talking about the old Mac OS < X Days
No, we don't need Type and Creator in the classical sense, we need the
comparison of the returned type to work against the constants defined
in NSWorkspace:
NSPlainFileType
Plain (untyped) file
NSDirectoryFileType
Directory
NSApplicationFileType
Cocoa application
NSFilesystemFileType
File-system mount point
NSShellCommandFileType
Executable shell command
right now only the extension is returned. If we would need just that
there were easier ways to get this.
Most Cocoa apps never use them.
The default implementation of the methods used for storing files to
disk ignore them.
You have to do extra work to store them.
Doesn't Apple consider them deprecated?
The Workspace tells you what the finder would do, or if it doesn't not
know
returns the suffix.
The suffix is thus returned as the type unless the Workspace knows
about
a type suffix -> document type based on an applications bundle
information.
If you really need that functionality, for identifying what files and
directories represent
You will probably have you do it yourself.
Well, because it doesn't work like it is documented it is a bug.
One can always do things on it's own, but that turns out to become a
huge amount of work, especially for a cross plattform solution
(GNUstep, Cocoa) like the one we are working on.
You could:
1. Cache the mounted filesytem list. From this you can get mount
points.
2. Use NSFilemanager to Identify, symbolic links, directories, and
devices, and FIFOs
3. Ask workspace manager to determine if a file has a defined type
a. If yes use that
b. If no, consult the magic number/pattern data in the first block
like the file(1) command.
Grab the magic file and file.c from FreeBSD to learn how.
4. Ask the workspace manager to determine if a directory a known type
of bundle or
NSFileWrapper that is treated as a file type.
greetings, Lars
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.