On May 22, 2008, at 2:35 AM, Mike Fischer wrote:
FSRefs are also highly filesystem-dependent,
They are? That's news to me. In what way?
Sorry, what I meant to say there was that the unique features offered
by FSRefs are filesystem-dependent - in other words, using it on a non-
HFS+ disk w
On 21 May '08, at 11:49 PM, Charles Srstka wrote:
Is it really vital functionality, though? Resource forks have been
deprecated for some time now, and FSRefs, while useful and well-
liked by many users, don't really seem to be on Apple's radar these
days.
There's a ton of other functional
On May 21, 2008, at 11:49 PM, Charles Srstka wrote:
FSRefs are also highly filesystem-dependent, and HFS+, the only file
system (as far as I know) that currently fully supports them, is
showing its age and ready to be replaced, possibly by a file system
like ZFS that wasn't invented by App
Am 22.05.2008 um 08:49 schrieb Charles Srstka:
Is it really vital functionality, though? Resource forks have been
deprecated for some time now, and FSRefs, while useful and well-
liked by many users, don't really seem to be on Apple's radar these
days.
Certain parts of Apple have never had
Am 22.05.2008 um 07:50 schrieb Charles Srstka:
On May 22, 2008, at 12:09 AM, Mike Fischer wrote:
Anyway I remember reading somewhere that Apple warned about
relying on ..namedfork/rsrc always working. I can't find the
reference at the moment though.
That was WWDC 2006, in which the speake
On May 22, 2008, at 1:40 AM, Jens Alfke wrote:
On 21 May '08, at 10:50 PM, Charles Srstka wrote:
What becomes the purpose of the Carbon File Manager, anyway?
Cocoa's already got a file manager. And yet even after seven years,
with all the new APIs, new language features, and new paradigms
On 21 May '08, at 10:50 PM, Charles Srstka wrote:
What becomes the purpose of the Carbon File Manager, anyway? Cocoa's
already got a file manager. And yet even after seven years, with all
the new APIs, new language features, and new paradigms that have
been added to Cocoa, its file manager
On May 22, 2008, at 12:09 AM, Mike Fischer wrote:
As I understand it only the GUI portions of Carbon are going out of
style. The lower level stuff like the File Manager seems to be
sticking around. (Well not the old FSSpec stuff but the modern FSRef
APIs.) Actually it seems like some things
Am 22.05.2008 um 06:11 schrieb Charles Srstka:
On May 21, 2008, at 11:11 AM, Mike Fischer wrote:
There are hacks that rely on special pathnames to access the
resource fork of a file. (Something like /path/to/file/..namedfork/
rsrc) But I would not recommend using them as there is no
guaran
On May 21, 2008, at 11:11 AM, Mike Fischer wrote:
There are hacks that rely on special pathnames to access the
resource fork of a file. (Something like /path/to/file/..namedfork/
rsrc) But I would not recommend using them as there is no guarantee
that they will continue to work in the future
Am 21.05.2008 um 15:34 schrieb Nick Rogers <[EMAIL PROTECTED]>:
Hi,
My app has to create the resource fork of a file and then write raw
bytes picked up from the disk to it.
Unless these "raw bytes" actually contain a valid Resource Manager
structure this would be a bad idea. Yes it is possib
On 21 May '08, at 6:14 AM, Nick Rogers wrote:
My app has to create the resource fork of a file and then write raw
bytes picked up from the disk to it.
Hopefully you're copying the contents of another file's resource fork,
i.e. you're copying or unarchiving a file. A file's resource fork
Hi,
My app has to create the resource fork of a file and then write raw
bytes picked up from the disk to it.
Is there any support in cocoa for this.
For writing to the data fork I'm creating the file with NSFileManager
and then writing using write().
Is there any similar mechanism for creat
13 matches
Mail list logo
