A Windows XP help forum. PCbanter

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » PCbanter forum » Microsoft Windows 7 » Windows 7 Forum
Site Map Home Register Authors List Search Today's Posts Mark Forums Read Web Partners

Can a Macintosh person tell us how to change the name of a file?



 
 
Thread Tools Rate Thread Display Modes
  #61  
Old December 14th 17, 07:39 PM posted to comp.sys.mac.apps,alt.windows7.general,comp.sys.mac.system
nospam
external usenet poster
 
Posts: 1,308
Default Can a Macintosh person tell us how to change the name of a file?

In article , Mayayana
wrote:

"Lewis" wrote
| HEIF is an excellent format with many modern advantages.

I'm guessing you're saying that because you use Apple
and Apple told you so, because Apple is switching to
it in iPhones.


no, it's because it's much better, with files typically around half the
size of a jpeg and with higher quality.

apple is the first to use it. others will follow.

First, it's a container format, not an image format.


that's a feature, and a very important and useful one, particularly
where non-destructive edits can be stored with the image.

Something like docx or like various compound
storage formats.


not really.

Second, the compression used seems to be very good, but
is it totally non-lossy? That's not clear from what I've read.


keep reading. both lossless and lossy are supported.

Third, and this is a biggie, the compression is patented:
https://www.hevcadvance.com/licensin...ng-information


lots of things are patented.

Apple is using a system that allows for flexibility like storing
different copies of the same image in one container.


that's not why they're using it and it's not apple's format either.

heif is an industry standard format that apple *and* others currently
support or will be supporting in the future.

https://en.wikipedia.org/wiki/High_Efficiency_Image_File_Format
High Efficiency Image File Format (HEIF, often pronounced
heef) is a file format for individual images and image sequences. It
was developed by the Moving Picture Experts Group (MPEG) and is
defined by MPEG-H Part 12 (ISO/IEC 23008-12).

And
presumably they're paying the patent fees.


presumably.

But that's not
needed for a basic file format.


it's much more than a basic file format. that's the point.

All that's needed is to develop
the best possible compression for bitmaps and then make
that format widely supported. Add a clear metadata storage
system and it does everything that anyone could want, at
least within the range of 24-bit color raster images.


which is what heif/hevc is intended to do, and a *****load* more.

But it needs to be a non-patented compression. Otherwise
it can't be used by most of the people who would want to
use it, like webmasters.


start he
https://github.com/nokiatech/heif
Ads
  #62  
Old December 14th 17, 07:44 PM posted to comp.sys.mac.system,alt.windows7.general,comp.sys.mac.apps
J. P. Gilliver (John)[_4_]
external usenet poster
 
Posts: 1,526
Default Can a Macintosh person tell us how to change the name of a file?

In message , Lewis
writes:
In message J. P. Gilliver (John)
wrote:
In message , Tim Streater
writes:
[]
When attachments are emailed, some of the metadata goes with it: at
least filename, creation and modification dates. This is all done using
the content-disposition: header (see RFC 2183).

When I send or receive attachments, I'm pretty sure no date information
is included.


Depends entirely on how you send them.

If I send them as normal, using Turnpike, Outlook, or Thunderbird. If I
want to retain dates, I make a zip file, which _does_ retain dates
(though I'm not sure if more than one) with each file within. If I just
save an attachment from Turnpike or Outlook, the file created gets a
creation date of the instant it's extracted.
--
J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)[email protected]+H+Sh0!:`)DNAf

You can be tough without being rude - Nick Clegg, 2014 July
  #63  
Old December 14th 17, 07:45 PM posted to comp.sys.mac.apps,alt.windows7.general,comp.sys.mac.system
Your Name
external usenet poster
 
Posts: 86
Default Can a Macintosh person tell us how to change the name of a file?

On 2017-12-14 06:31:41 +0000, Paul said:
Your Name wrote:
On 2017-12-14 03:16:11 +0000, Wolf K said:

That's what Open With is for.


Open With is near useless if you don't know what the file actually is.
You'd have to Open With with every app you have until you found one
that could open it properly.


If you don't have any tools, and are on a desert island,
you use "Open With" "Wordpad" to figure out what something
is. It's not that hard.


Only if the file itself contains some clue within it as to what the
document type is ... many don't bother with that, so you're stuck
trying to open it in every app you have.

  #64  
Old December 14th 17, 07:46 PM posted to comp.sys.mac.apps,alt.windows7.general,comp.sys.mac.system
Lewis
external usenet poster
 
Posts: 338
Default Can a Macintosh person tell us how to change the name of a file?

In message Mayayana wrote:
"Lewis" wrote


| HEIF is an excellent format with many modern advantages.
|


I'm guessing you're saying that because you use Apple
and Apple told you so, because Apple is switching to
it in iPhones.


You can guess what you wish.

First, it's a container format, not an image format.


You can feel free to make that meaningless distinction if you want.
While technically correct it is pointless. HEIF contains HEVC and
H.264/MPEG-4 AVC and might contain a JPEG thumbnail (up to 4K
resolution) for display purposes. It's not going to contain, for
example, a GIF or BMP image.

Second, the compression used seems to be very good, but
is it totally non-lossy? That's not clear from what I've read.


"Lossless images" is the new "vinyl is best" idiocy.

Third, and this is a biggie, the compression is patented:
https://www.hevcadvance.com/licensin...ng-information


OHNOES!HOW DREADFUL! WE'VE NEVER EVER HAD A PATENTED FORMAT BEFORE
except for, you know, all of them.

Patents expire. If you're a FOSS moron you can wait the 17 years.

Apple is using a system that allows for flexibility like storing
different copies of the same image in one container.


Which is part of the spec.

| No one can force MS to make that public or standardize the structure.
|
| Well, that is certainly not true.
|


No? A company doesn't have a right to
keep proprietary technologies secret?


That is not what I said. You made a false and incorrect statement and I
pointed out it was false.

Perhaps you'd like to tell us the Coke recipe.


Which has nothing to do with anything. Thanks for playing.

--
Live long enough to become a problem to your kids.
  #65  
Old December 14th 17, 07:56 PM posted to comp.sys.mac.system,alt.windows7.general,comp.sys.mac.apps
Lewis
external usenet poster
 
Posts: 338
Default Can a Macintosh person tell us how to change the name of a file?

In message J. P. Gilliver (John) wrote:
In message , Lewis
writes:
In message J. P. Gilliver (John)
wrote:
In message , Tim Streater
writes:
[]
When attachments are emailed, some of the metadata goes with it: at
least filename, creation and modification dates. This is all done using
the content-disposition: header (see RFC 2183).

When I send or receive attachments, I'm pretty sure no date information
is included.


Depends entirely on how you send them.

If I send them as normal, using Turnpike, Outlook, or Thunderbird. If I
want to retain dates, I make a zip file, which _does_ retain dates
(though I'm not sure if more than one) with each file within. If I just
save an attachment from Turnpike or Outlook, the file created gets a
creation date of the instant it's extracted.


And there are many ways (countless ways) to send attachments. Many of
them are entirely transparent to the user, so without digging they may
have no idea how they are sent or what metadata is preserved.

--
NO ONE WANTS TO HEAR FROM MY ARMPITS Bart chalkboard Ep. 3F01
  #66  
Old December 14th 17, 08:01 PM posted to comp.sys.mac.apps,alt.windows7.general,comp.sys.mac.system
Paul[_32_]
external usenet poster
 
Posts: 5,812
Default Can a Macintosh person tell us how to change the name of a file?

Your Name wrote:
On 2017-12-14 06:31:41 +0000, Paul said:
Your Name wrote:
On 2017-12-14 03:16:11 +0000, Wolf K said:

That's what Open With is for.

Open With is near useless if you don't know what the file actually
is. You'd have to Open With with every app you have until you found
one that could open it properly.


If you don't have any tools, and are on a desert island,
you use "Open With" "Wordpad" to figure out what something
is. It's not that hard.


Only if the file itself contains some clue within it as to what the
document type is ... many don't bother with that, so you're stuck trying
to open it in every app you have.


I have *many* techniques for file identification and disassembly.

For example, I upload small files to virustotal.com, to provide
"hints" in cases where the unpackers the AV tools have,
can provide info I can use.

Opening them in every app is *never* used. Not ever.

I'm too lazy to do that :-)

Doing that implies "the terrorists have won".

Obviously, there are files with crypto applied, and
no metadata hints or 4CC codes or anything in them.
And unless you know of an app that definitely handles
a wide range of crypto, you'd say "forget it". I don't
even think I have any examples like that, unless
I made them myself like this.

dd if=/dev/random of=C:\gee_whats_this bs=512 count=10000

Feeding that to "all the apps" won't work for sure.

I use files like that to test data compressors,
to see if they handle the file properly.

Paul
  #67  
Old December 14th 17, 08:02 PM posted to comp.sys.mac.apps,alt.windows7.general,comp.sys.mac.system
Your Name
external usenet poster
 
Posts: 86
Default Can a Macintosh person tell us how to change the name of a file?

On 2017-12-14 13:22:54 +0000, Mayayana said:
"Tim Streater" wrote
|
| The type of a file and which app you'd like it to open with are items
| of file metadata and have no business being part of the filename.
|
| Many files have such type-identifiers included. E.g., a JPG file begins
| with JFIF, a WordPerfect file includes WPC in the first line, an MS .doc
|
| Then you've put the metadata inside the file, which is even worse. It
| should be part of the file system.

This is the problem with mixing Mac and Windows
discussions. As I understand it, Mac stores file data
separately as a "resource fork". Mac users are not
expected to understand anything about files. That's
not the same as metadata.


Resource forks died with the Classic versions of Mac OS (the very last
version released was 9.2.2 in December 2001), although Mac OS X does
know how deal with them.

Resource forks are usually only used by applications - normal document
/ data files do not have resource forks, so they are not how the OS
knows which application to open a document in. In the application, the
resource fork does contain the information used to establish which
application the document was created / modified in.

Mac OS X applications do still have resources, but they're stored
within a normal file structure, so aren't affected corruption issues
.... although the extra folders and files (including Finder specific
data files on disks or in Zip archives) may cause confusion for Windows
users.




Resource fork used to be a problem when Mac users
emailed photos. If they didn't know to strip the Mac-
specific prepended data they'd send a corrupt file.


Nope, not a Mac user problem, and photos, being document / data files,
don't normally have resources forks anyway.

The application files emailed were corrupted by Windows (either the OS
on the receiver's computer or the OS on the servers the file travelled
through) not knowing how to handle the two forks. Applications files
could also be corrupted by trying to transfer them on Windows formatted
disks. Either way, this was easily worked around by first compressing
the application file using a Mac archiving utility such as Compact Pro
or StuffIt.



  #68  
Old December 14th 17, 08:14 PM posted to comp.sys.mac.apps,alt.windows7.general,comp.sys.mac.system
Your Name
external usenet poster
 
Posts: 86
Default Can a Macintosh person tell us how to change the name of a file?

On 2017-12-14 14:21:12 +0000, Wolf K said:

On 2017-12-14 00:24, Your Name wrote:
On 2017-12-14 03:16:11 +0000, Wolf K said:

On 2017-12-13 19:37, Your Name wrote:

[...]
* ... you can't rely on the OS to do that since a JPEG image file can
actually be opened in a text editor as the file's data, even if it's
rarely useful to do so.

That's what Open With is for.


Open With is near useless if you don't know what the file actually is.
You'd have to Open With with every app you have until you found one
that could open it properly.


If we're talking about user convenience, I agree, showing a file's type
as part of the filename is very useful. (But IMO a three-letter
extension is too limited). There are many other useful conventions, eg,
in icon design. These are converging on a common standard.


I don't know about Windows, but Mac OS X can have at least four letter
extensions (.tiff, .jpeg, .html for example).

Perhaps a bigger issue is using the "." character as the separator
(although some OSes apparently use a space instead, which is even
worse).



If we're talking about choosing a program to open a file, extenions
aren't needed. It would be easy to ensure that Open With offers only
programs that can open a given file without reference to an extension.
Just standardise metadata (eg, as a series of slots, some which must be
filled, others for dev or user options). Easy peasy.


Perhaps, but that means establishing another new "standard" for
developers to follow (not all files currently have such data within
them). It also means the OS has to physically read the files to find
out what they are, which maybe isn't so much of an issue with today's
fast CPUs and storage drives, but could be for those using server-based
storage via slow (or data capped) network / internet connections.

BUT,
Microsoft can't stick to anyone else's standard and always tries to
make up their own ideas and then force everyone else to follow them.
Internet Explorer being an obvious example that caused many headaches
for web developers thanks to using it's own silly ideas rather than the
establised HTML standard.




  #69  
Old December 14th 17, 08:19 PM posted to comp.sys.mac.apps,alt.windows7.general,comp.sys.mac.system
nospam
external usenet poster
 
Posts: 1,308
Default Can a Macintosh person tell us how to change the name of a file?

In article , Your Name
wrote:


I don't know about Windows, but Mac OS X can have at least four letter
extensions (.tiff, .jpeg, .html for example).


longer than that.

Perhaps a bigger issue is using the "." character as the separator
(although some OSes apparently use a space instead, which is even
worse).


which oses would those be??
  #70  
Old December 14th 17, 08:19 PM posted to comp.sys.mac.apps,alt.windows7.general,comp.sys.mac.system
nospam
external usenet poster
 
Posts: 1,308
Default Can a Macintosh person tell us how to change the name of a file?

In article , Your Name
wrote:


Resource forks died with the Classic versions of Mac OS (the very last
version released was 9.2.2 in December 2001), although Mac OS X does
know how deal with them.


no they didn't. resource forks are very much alive and are still used
to this day on mac os x (although their use is declining).

Resource forks are usually only used by applications - normal document
/ data files do not have resource forks,


many of them did have resource forks.

so they are not how the OS
knows which application to open a document in.


that part is correct. that information is the finder info.

In the application, the
resource fork does contain the information used to establish which
application the document was created / modified in.


nope. that's kept in the desktop database.

Mac OS X applications do still have resources, but they're stored
within a normal file structure, so aren't affected corruption issues
... although the extra folders and files (including Finder specific
data files on disks or in Zip archives) may cause confusion for Windows
users.


mac os x apps are bundles, however, individual files can (and often do)
have resource forks.

Resource fork used to be a problem when Mac users
emailed photos. If they didn't know to strip the Mac-
specific prepended data they'd send a corrupt file.


Nope, not a Mac user problem, and photos, being document / data files,
don't normally have resources forks anyway.


sometimes they did, however, losing the resource fork in a transfer did
not corrupt the image itself.

The application files emailed were corrupted by Windows (either the OS
on the receiver's computer or the OS on the servers the file travelled
through) not knowing how to handle the two forks. Applications files
could also be corrupted by trying to transfer them on Windows formatted
disks. Either way, this was easily worked around by first compressing
the application file using a Mac archiving utility such as Compact Pro
or StuffIt.


no.
  #71  
Old December 14th 17, 08:28 PM posted to comp.sys.mac.apps,alt.windows7.general,comp.sys.mac.system
Andre G. Isaak
external usenet poster
 
Posts: 27
Default Can a Macintosh person tell us how to change the name of a file?

In article , Wolf K
wrote:

On 2017-12-14 10:18, nospam wrote:
In article , Tim Streater
wrote:

| The type of a file and which app you'd like it to open with are
| items
| of file metadata and have no business being part of the filename.

| Many files have such type-identifiers included. E.g., a JPG file
| begins
| with JFIF, a WordPerfect file includes WPC in the first line, an MS
| .doc

| Then you've put the metadata inside the file, which is even worse. It
| should be part of the file system.

This is the problem with mixing Mac and Windows
discussions. As I understand it, Mac stores file data
separately as a "resource fork".

No, you have it back to front. File data went in the data fork,
metadata went in the resource fork.


no it didn't.

metadata was kept in the file system.

the resource fork (which was optional, as was the data fork) held
various resources. it was basically a miniature database.

a zero-length file would have an empty data *and* resource fork. rare,
but possible.

Unfortunately Apple has abandoned
this idea and settled for the lowest-common-denominator approach, and
w're all the worse off for it.


yep.


Educate me. What's the advantage of the "forks"? As described, it looks
like metadata with a fancy name, apparently conceived as attached to or
pointed to by the file. Presumably it's stored separately from the file.


Resource Forks are completely unrelated to metadata.

The 2-fork architecture was inherited from Classic Mac OS, and, while
still supported by mac OS X, it is used much less frequently.

In Classic Mac OS, every file consisted of two separate forks (either of
which could be empty).

The Resource Fork contained structured data which was managed by the
operating system which defined a wide variety of resource types (though
applications could define there own). These included GUI elements like
menu templates, window templates, dialog item lists, icons etc. as well
as things like fonts, device drivers, executable code segments, keyboard
layouts etc.

The data fork contained anything the application which created the file
wanted to put there and the application was responsible for interpreting
and organizaing that data.

Metadata wasn't stored in either fork. It was stored in the desktop
database which was maintained by the finder.

The advantage of the resource fork was simply that it made the mac much
easier to program since datatypes used by the OS were entirely managed
by the OS rather than the application (and it made it easier to
customize the GUI of existing applications).

The majority of files which one would actually want to distribute
cross-platform would have only a data fork as files which made use of
the resource fork were generally mac-only files anyways. The bigger
problem back in the day was transferring mac files to another mac across
another system (Windows, *nix, etc.) which didn't recognize the resource
fork.

Andre

--
To email remove 'invalid' & replace 'gm' with well known Google mail service.
  #72  
Old December 14th 17, 08:31 PM posted to comp.sys.mac.apps,alt.windows7.general,comp.sys.mac.system
J. P. Gilliver (John)[_4_]
external usenet poster
 
Posts: 1,526
Default Can a Macintosh person tell us how to change the name of a file?

In message , Lewis
writes:
In message Mayayana
wrote:

[]
Second, the compression used seems to be very good, but
is it totally non-lossy? That's not clear from what I've read.


"Lossless images" is the new "vinyl is best" idiocy.

[]
No. "Vinyl is best" is based on (currently) unmeasurable perceptions.
(Granted, _some_ of them - abstruse harmonic interactions perhaps - may
come to light in time.)

Lossless image compression is, in contrast, a measurable matter: an
image, after compression and then expansion, can be compared to the
original, and it can thus be clearly stated whether there is any loss or
not.
--
J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)[email protected]+H+Sh0!:`)DNAf

This was before we knew that a laboratory rat, if experimented upon, will
develop cancer. [Quoted by] Anne ), 1997-1-29
  #73  
Old December 14th 17, 08:54 PM posted to comp.sys.mac.apps,alt.windows7.general,comp.sys.mac.system
nospam
external usenet poster
 
Posts: 1,308
Default Can a Macintosh person tell us how to change the name of a file?

In article ,
Andre G. Isaak wrote:


Unfortunately Apple has abandoned
this idea and settled for the lowest-common-denominator approach, and
w're all the worse off for it.

yep.


Educate me. What's the advantage of the "forks"? As described, it looks
like metadata with a fancy name, apparently conceived as attached to or
pointed to by the file. Presumably it's stored separately from the file.


Resource Forks are completely unrelated to metadata.

The 2-fork architecture was inherited from Classic Mac OS, and, while
still supported by mac OS X, it is used much less frequently.

In Classic Mac OS, every file consisted of two separate forks (either of
which could be empty).

The Resource Fork contained structured data which was managed by the
operating system which defined a wide variety of resource types (though
applications could define there own). These included GUI elements like
menu templates, window templates, dialog item lists, icons etc. as well
as things like fonts, device drivers, executable code segments, keyboard
layouts etc.

The data fork contained anything the application which created the file
wanted to put there and the application was responsible for interpreting
and organizaing that data.

Metadata wasn't stored in either fork. It was stored in the desktop
database which was maintained by the finder.


a good summary.

The advantage of the resource fork was simply that it made the mac much
easier to program since datatypes used by the OS were entirely managed
by the OS rather than the application (and it made it easier to
customize the GUI of existing applications).


it also meant that end users could easily modify existing apps (or even
the system itself) by modifying and/or replacing resources, and in some
cases, add (or remove) additional functionality.

The majority of files which one would actually want to distribute
cross-platform would have only a data fork as files which made use of
the resource fork were generally mac-only files anyways. The bigger
problem back in the day was transferring mac files to another mac across
another system (Windows, *nix, etc.) which didn't recognize the resource
fork.


true, although standard file types (text, jpg, etc.), often stored
extra stuff in the resource fork alongside the file data, including
window size/position, scroll position, zoom level, etc., and if that's
lost when transferring to another system, no big deal. it just uses the
defaults.

all three parts (data & resource forks plus finder info) could be
combined into a single entity (macbinary) so that it could be hosted on
non-mac system without losing anything which was normally done
automatically by mac comms software and generally where compatibility
issues arose because that blob was no longer a standard jpeg, text or
whatever format anymore.
  #74  
Old December 14th 17, 09:59 PM posted to comp.sys.mac.system,comp.sys.mac.apps,alt.windows7.general
Krzysztof Mitko
external usenet poster
 
Posts: 1
Default Can a Macintosh person tell us how to change the name of a file?

Your Name wrote:
On 2017-12-14 14:21:12 +0000, Wolf K said:

On 2017-12-14 00:24, Your Name wrote:
On 2017-12-14 03:16:11 +0000, Wolf K said:

On 2017-12-13 19:37, Your Name wrote:

[...]
* ... you can't rely on the OS to do that since a JPEG image file can
actually be opened in a text editor as the file's data, even if it's
rarely useful to do so.

That's what Open With is for.

Open With is near useless if you don't know what the file actually is.
You'd have to Open With with every app you have until you found one
that could open it properly.


If we're talking about user convenience, I agree, showing a file's type
as part of the filename is very useful. (But IMO a three-letter
extension is too limited). There are many other useful conventions, eg,
in icon design. These are converging on a common standard.


I don't know about Windows, but Mac OS X can have at least four letter
extensions (.tiff, .jpeg, .html for example).


..webarchive, .pages, .workflow… But AFAIR Windows is not limited to
three-letter extensions either.

Perhaps a bigger issue is using the "." character as the separator
(although some OSes apparently use a space instead, which is even
worse).


Which ones?

If we're talking about choosing a program to open a file, extenions
aren't needed. It would be easy to ensure that Open With offers only
programs that can open a given file without reference to an extension.
Just standardise metadata (eg, as a series of slots, some which must be
filled, others for dev or user options). Easy peasy.


Perhaps, but that means establishing another new "standard" for
developers to follow (not all files currently have such data within
them).


Unix “file” command already exist.

It also means the OS has to physically read the files to find
out what they are, which maybe isn't so much of an issue with today's
fast CPUs and storage drives, but could be for those using server-based
storage via slow (or data capped) network / internet connections.

BUT,
Microsoft can't stick to anyone else's standard and always tries to
make up their own ideas and then force everyone else to follow them.
Internet Explorer being an obvious example that caused many headaches
for web developers thanks to using it's own silly ideas rather than the
establised HTML standard.


--
Chemical engineers do it in packed beds.
  #75  
Old December 15th 17, 12:31 AM posted to comp.sys.mac.system,alt.windows7.general,comp.sys.mac.apps
Your Name
external usenet poster
 
Posts: 86
Default Can a Macintosh person tell us how to change the name of a file?

On 2017-12-14 20:28:16 +0000, Andre G. Isaak said:
In article , Wolf K
wrote:
On 2017-12-14 10:18, nospam wrote:
In article , Tim Streater
wrote:
| The type of a file and which app you'd like it to open with are
| items
| of file metadata and have no business being part of the filename.

| Many files have such type-identifiers included. E.g., a JPG file
| begins
| with JFIF, a WordPerfect file includes WPC in the first line, an MS
| .doc

| Then you've put the metadata inside the file, which is even worse. It
| should be part of the file system.

This is the problem with mixing Mac and Windows
discussions. As I understand it, Mac stores file data
separately as a "resource fork".

No, you have it back to front. File data went in the data fork,
metadata went in the resource fork.

no it didn't.

metadata was kept in the file system.

the resource fork (which was optional, as was the data fork) held
various resources. it was basically a miniature database.

a zero-length file would have an empty data *and* resource fork. rare,
but possible.

Unfortunately Apple has abandoned
this idea and settled for the lowest-common-denominator approach, and
w're all the worse off for it.

yep.


Educate me. What's the advantage of the "forks"? As described, it looks
like metadata with a fancy name, apparently conceived as attached to or
pointed to by the file. Presumably it's stored separately from the file.


Resource Forks are completely unrelated to metadata.

The 2-fork architecture was inherited from Classic Mac OS, and, while
still supported by mac OS X, it is used much less frequently.

In Classic Mac OS, every file consisted of two separate forks (either of
which could be empty).

snip

Wrong.

Purely data files, such as a JPEG image or Word document, did not have
any resource fork at all, not even an empty one. They didn't need one
because there are no resources. That's why if you try to open a data
file in ResEdit it says there is no resource fork and asks if you want
to add one. (An optional add-on did allow ResEdit to open the data
fork).

Mainly it was only applications that had resource forks.


Many people confuse the Finder's information as being part of the
resource fork, but they are different. The Finder's information is not
stored inside the file at all.



 




Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off






All times are GMT +1. The time now is 05:29 PM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.
Copyright 2004-2018 PCbanter.
The comments are property of their posters.