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
  #91  
Old December 15th 17, 02:13 PM posted to comp.sys.mac.system,alt.windows7.general,comp.sys.mac.apps
J. P. Gilliver (John)[_4_]
external usenet poster
 
Posts: 2,679
Default Can a Macintosh person tell us how to change the name of a file?

In message , Mayayana
writes:
"J. P. Gilliver (John)" wrote

| You seem to just make things up on the spot. There
| are not "many" ways to send attachments in email.
|
| Yes there are.
|
| Indeed. Some of which most modern email/news software doesn't know
| about: for example, I can embed an attachment at any point within an
| email, and someone else using the same software will see what I sent,
| but someone using most other software will see the text I typed before
| the attachment, then two attachments - the one I embedded being one, and
| the text that came after being the other. [Most modern softwares
| _always_ put attachments at the end, perhaps putting a _link_ (often
| "cid:") in the body if they want to make it _appear_ that the attachment
| isn't at the end.]

You're describing the two versions of the same thing:
Inline and attachment. If the recipient doesn't enable


Nope. What I mean is that if I place an image (or any other attachment)
_in the middle of an email/post_, and examine the raw text of my email,
then it had the (UU or Mime/64) block _in the middle of the email_, i.
e. the text after the attachment actually _is_ after the attachment. If
you drop me an email with your email, I'll send you and example. (Can't
post one as this is a text-only 'group.)

HTML email then they should see an inline image as an
attachment. Otherwise they'll see it where you put
it in the message. Both are base64-encoded text
sections in the email. There's no difference in that.


Nope: nothing to do with HTML. If I send a truly inline image, _in the
middle of an email/post_, most other clients will see the image _and the
text that follows it_ as two attachments.

As you noted, the "cid:" ID will point to a Content-ID
in another content section to specify the image that
should be rendered. If it's meant to be an attachment
it will have Content-Disposition: attachment. That's all
specified in the MIME standard. I'm not aware of any
other formats in use for email.
https://en.wikipedia.org/wiki/MIME

Maybe 30 years ago old guys like you and Fred Flinstone
sent uuencoded pictures.

I _think_ that's a separate matter, of how attachments (including
pictures) are encoded (UU or Mime/64).


3
--
J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

"Eastenders" is like being punched repeatedly in the face for half an hour. -
Stephen Mangan, in Radio Times 5-11 May 2012
Ads
  #92  
Old December 15th 17, 02:37 PM posted to comp.sys.mac.apps,alt.windows7.general,comp.sys.mac.system
nospam
external usenet poster
 
Posts: 4,718
Default Can a Macintosh person tell us how to change the name of a file?

In article , Alan Baker
wrote:

| 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.


Ummmm... ...no.

Some metadata was COPIED to the desktop database, et al.


in other words, yes.
  #93  
Old December 15th 17, 02:38 PM posted to comp.sys.mac.system,alt.windows7.general,comp.sys.mac.apps
Mayayana
external usenet poster
 
Posts: 6,438
Default Can a Macintosh person tell us how to change the name of a file?

"J. P. Gilliver (John)" wrote

| HTML email then they should see an inline image as an
| attachment. Otherwise they'll see it where you put
| it in the message. Both are base64-encoded text
| sections in the email. There's no difference in that.
|
| Nope: nothing to do with HTML. If I send a truly inline image, _in the
| middle of an email/post_, most other clients will see the image _and the
| text that follows it_ as two attachments.

If you add an inline image that is HTML. If you
look at the raw code of the email you should see
the email specified as multi-part. A unique boundary
string will separate text/html/binaries. You can only
add an inline image in an HTML section, and that
image data can only go in a separate boundaried
content section.

I wonder if maybe this has to do with how you're
using the client software itself. In theory there's
no reason that an image can't come before text,
but it still has to be in a different content section
with a boundary, because only one type of content
goes in a section. And I've never seen it done. In
virtually all cases, an email is done in plain text, followed
by HTML, followed by any base64-encoded files. A
plain text email would skip the HTML section.

Maybe you're trying to put inline images in a
plain text email and the software is "humoring you"?

______________________________
plain text with attachments
______________________________

from
to
date
subject
Message-ID
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="BOUNDARY_STRING_1"
X-Mailer: [your program name here]
#
--BOUNDARY_STRING_1
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
#
(email text here)
#
--BOUNDARY_STRING_1
Content-Type: image/jpeg;
name="earth_sm.jpg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="earth_sm.jpg"
#
(base 64 here)
#
--BOUNDARY_STRING_1--

_________________________
HTML with pictures
_________________________

from
to
subject
date
Message-ID
MIME-Version: 1.0
Content-Type: multipart/related;
boundary="BOUNDARY_STRING_1";
type="multipart/alternative"
X-Mailer: [your program name here]
#
--BOUNDARY_STRING_1
Content-Type: multipart/alternative;
boundary="BOUNDARY_STRING_2"
#
--BOUNDARY_STRING_2
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
#
(default text for non-html email readers)
#
--BOUNDARY_STRING_2
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
#
(html body here.......
IMG SRC=3D"cidic.gif"
......)
#
--BOUNDARY_STRING_2-- (end of alternative boundary.)
#
--BOUNDARY_STRING_1
Content-Type: image/gif; (or image/jpg, etc.)
name="pic.gif"
Content-Transfer-Encoding: base64
Content-ID: pic.gif
#
(base 64 here)
# (repeat for other pics if present: space, boundary,
content, space, base64, space)
--BOUNDARY_STRING_1--


  #94  
Old December 15th 17, 04:15 PM posted to comp.sys.mac.system,alt.windows7.general,comp.sys.mac.apps
Mayayana
external usenet poster
 
Posts: 6,438
Default Can a Macintosh person tell us how to change the name of a file?

"Tim Streater" wrote |

| Content Disposition
| *can* be used to send creation/modification date.
| I've never actually seen it done. It's certainly not
| required.
|
| I never said it was required. I added it to my email client because I'd
| seen those fields arriving in some content-disposition headers.
|

That's very different from the idea that an email
client is "rubbish" if it doesn't do it. I have OE and
TBird here. Neither one sets to mod date. Not that
I'd mind if they did, but I can't say I'd ever noticed
one way or the other. If someone sends me a photo
of their new baby it's not particularly relevant to
me what day they took the photo.

| And sending creation date would make
| no sense. Your copy is created when you get it,
| just as a file copied across partitions has a creation
| date corresponding to when it was copied.
|
| No it doesn't. I just copied a file to my desktop from another Mac on
| the local LAN (by drag and drop), and the copy on my desktop has the
| same creation date as the original. Which is what I'd expect any
| sensible system to do.
|

And it's a copy, not a link? Maybe that's the
Mac standard. On Windows a copy has the same
modification date but a different creation date.

To give it the same creation time is to say that
both files are the same file; that there are no
actual copies and therefore the copy
was never actually created. Thus it's only an
alternate manifestation of the same, exact item.
Sounds like some pretty funky, existential hocus
pocus to me.



  #95  
Old December 15th 17, 04:31 PM posted to comp.sys.mac.system,alt.windows7.general,comp.sys.mac.apps
nospam
external usenet poster
 
Posts: 4,718
Default Can a Macintosh person tell us how to change the name of a file?

In article , Mayayana
wrote:

| And sending creation date would make
| no sense. Your copy is created when you get it,
| just as a file copied across partitions has a creation
| date corresponding to when it was copied.
|
| No it doesn't. I just copied a file to my desktop from another Mac on
| the local LAN (by drag and drop), and the copy on my desktop has the
| same creation date as the original. Which is what I'd expect any
| sensible system to do.
|

And it's a copy, not a link? Maybe that's the
Mac standard. On Windows a copy has the same
modification date but a different creation date.

To give it the same creation time is to say that
both files are the same file;


a copy of something means both are *the* *same*.

if *anything* is different, then it's not a copy.
  #96  
Old December 15th 17, 05:32 PM posted to comp.sys.mac.system,alt.windows7.general,comp.sys.mac.apps
Mayayana
external usenet poster
 
Posts: 6,438
Default Can a Macintosh person tell us how to change the name of a file?


"Tim Streater" wrote

| You seem to just make things up on the spot. There
| are not "many" ways to send attachments in email.
| There's a format. All attachments are base64 encoded.
|
| No they aren't. Plain ASCII text and quoted-printable are also
| possible, and the sender has to declare which it is using the
| content-transfer-encoding: header, so that the receiver knows how to
| decode it.
|
I'm not sure all this nitpicking is getting
anywhere. There seems to be a lot of difference
in how terms are used. You call metadata any
info about a file. That's not technically wrong,
but usually when people are talking about
metadata they're talking about data embedded
in the file header, such a author of a JPG or artist
for a music file.

Here you seem to be using different terminology
again. Most people think of an email attachment
as a separate file that goes along with the email.
Those are always base64-encoded. ASCII and
quoted printable are not used for attachments.
They're specifying the text encoding. Maybe you're
confused by the term "encoding". Text encoding
refers to how the text is interpreted. For instance,
ASCII vs UTF-8. But it's still text. Base-64 is an
ASCII encoding of bytes, used to package binary
files in an ASCII medium.

One reads like this.

The other reads like:
hAiY1fTYddQJhLjnf+auTeCYAQAiG+u1TNA

The characters are not representing any kind
of text. Each is representing 6 bits of data that
could be anything.

You say you wrote an email client and you keep
referring to RFC docs. Surely you must know the
difference between plain text, html and attached
files in an email. Do you just like to be difficult?


  #97  
Old December 15th 17, 11:18 PM posted to comp.sys.mac.apps,alt.windows7.general,comp.sys.mac.system
nospam
external usenet poster
 
Posts: 4,718
Default Can a Macintosh person tell us how to change the name of a file?

In article , Wolf K
wrote:

[...] The internet works because the necessary data for routing the
data packets are inside the data packet, not external. That principle
should apply to all forms of data. Including programs, but that's a
another issue. mime headers say otherwise.
I don't see the relevance of your remark.


you mangled the quoting and you don't understand the issues.

AIUI, each data packet includes an ID to ensure that the intended
recipient computer can snag it from the data stream, and assemble the
packets in correct order, including the MIME header at the start of the
data. If you want to quibble about whether the ID data is inside the
packet or not, go ahead, quibble. Anything to keep you happy.


the mime headers are *not* part of the actual data. they *describe* the
data that is sent.


Dear, dear, tsk, tsk, more misreading. But then I knew you would.


there's no misreading whatsoever.

the mime headers describe the data that follows. that's why they're
called headers.

Even MIME headers are sent as data packets. Everything that's sent over
the internet is sent as data packets. It's the only way to do it.
Otherwise everyone would receive everything. Which would be a humongous
mess, which would take several lifetimes of the universe to sort out.


true, but completely irrelevant.

Have a nice quibbly, nit-picky day.


you too.
  #98  
Old December 15th 17, 11:38 PM posted to comp.sys.mac.apps,alt.windows7.general,comp.sys.mac.system
Mayayana
external usenet poster
 
Posts: 6,438
Default Can a Macintosh person tell us how to change the name of a file?

"Wolf K" wrote

| HEIF is not proprietary.

No. But the compression is that Apple is using,
and the compression efficiency of that method
seems to be what's appealing. In looking this up
I didn't see any examples of a high quality image
file using HEIF that's not using patented
compression.



  #99  
Old December 16th 17, 12:14 AM posted to comp.sys.mac.system,alt.windows7.general,comp.sys.mac.apps
Char Jackson
external usenet poster
 
Posts: 10,449
Default Can a Macintosh person tell us how to change the name of a file?

On Fri, 15 Dec 2017 08:47:47 -0000 (UTC), Lewis
wrote:

In message Char Jackson wrote:
On Thu, 14 Dec 2017 17:24:34 -0000 (UTC), Lewis
wrote:


In message Paul wrote:
Wolf K wrote:
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.

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.

Have a good day,


Windows is not limited to 8.3.

Might not be in Windows 10 (though I think it is)


Nope. I can't remember what happened before XP, but at least with XP
through 10 you can create a filename with 200+ characters in the
extension, as long as you don't exceed the total number of characters
allowed.


Please reread what I said, that file will have an 8.3 representation in
the filesystem. This was true in XP and in Windows 7 and in Windows 8
(Hmm. now I'm not positive about Windows 8).


Let's try again. Windows filenames are not limited to 8.3.

Not in Win 10, not in 8.x, not in 7, not in Vista, not in XP. I'll stop
there because I don't personally remember when Long Filename (LFN)
support was introduced, but it was somewhere before that, possibly in
Win 95.

If you think that Windows filenames *are* limited to 8.3, then you're
probably confusing 'long' filenames with 'short' filenames.

I'm not confusing them at all, I am pointing out taht both still exist,
and that the 8.3 name is required.


No. See above.

--

Char Jackson
  #100  
Old December 16th 17, 01:10 AM posted to comp.sys.mac.system,alt.windows7.general,comp.sys.mac.apps
Alan Baker
external usenet poster
 
Posts: 111
Default Can a Macintosh person tell us how to change the name of a file?

On 2017-12-14 4:31 PM, Your Name wrote:
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.




Would you care to explain, then, how the Finder knows what information
to apply to which file?
  #101  
Old December 16th 17, 01:13 AM posted to comp.sys.mac.system,alt.windows7.general,comp.sys.mac.apps
nospam
external usenet poster
 
Posts: 4,718
Default Can a Macintosh person tell us how to change the name of a file?

In article , Wolf K
wrote:

On 2017-12-14 19:31, Your Name wrote:
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.


Thank you.


be aware that the first part is completely wrong, as i said yesterday.

*every* files had *both* a resource *and* data fork (either or both of
which could be empty), including what he calls 'purely data files',
otherwise known as documents.

inside mac, volume i, page 105-6:
https://i.imgur.com/88pKuDl.jpg
https://i.imgur.com/ESsqRji.jpg

documents used the data fork, resource fork or both, depending on what
worked best for that particular app. for example, text editors would
put the text in the data fork (and compatible with non-mac systems),
but might also include a custom font or scroll position in the resource
fork. preference files often used only the resource fork.

applications had code & assets in the resource fork, with the data fork
often used for personalization (name, serial#, etc.) but could also be
used for many other things or could be empty.
  #102  
Old December 16th 17, 01:30 AM posted to comp.sys.mac.system,alt.windows7.general,comp.sys.mac.apps
Your Name
external usenet poster
 
Posts: 125
Default Can a Macintosh person tell us how to change the name of a file?

On 2017-12-16 00:10:04 +0000, Alan Baker said:

On 2017-12-14 4:31 PM, Your Name wrote:
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.


Would you care to explain, then, how the Finder knows what information
to apply to which file?


The Classic MacOS uses information stored within the Finder's own
invisible information files to understand what application to use with
each document file, the three usual ones being "Desktop DB", "Desktop
DF", and "TheVolumeSettingsFolder". These show up under Windows, which
was another cause of confusion for some users.

This is why rebuilding the database was sometimes necessary to fix
minor quirks (such as incorrect icons, especially when creating custom
icons).

MacOS X works in a similar way and has its Finder has different set of
invisible information files to keep track of such things.


  #103  
Old December 16th 17, 01:34 AM posted to comp.sys.mac.system,alt.windows7.general,comp.sys.mac.apps
Alan Baker
external usenet poster
 
Posts: 111
Default Can a Macintosh person tell us how to change the name of a file?

On 2017-12-15 4:30 PM, Your Name wrote:
On 2017-12-16 00:10:04 +0000, Alan Baker said:

On 2017-12-14 4:31 PM, Your Name wrote:
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.


Would you care to explain, then, how the Finder knows what information
to apply to which file?


The Classic MacOS uses information stored within the Finder's own
invisible information files to understand what application to use with
each document file, the three usual ones being "Desktop DB", "Desktop
DF", and "TheVolumeSettingsFolder". These show up under Windows, which
was another cause of confusion for some users.


Yes, yes, yes...

.....I understand that very well.

But what is the SOURCE for the information in the first place?

And do you imagine that the Desktop DB, Desktop DF, etc. had individual
entries for EVERY FILE on a hard drive?

If not, then each FILE has to contain information about what KIND of
file it is.

This is why rebuilding the database was sometimes necessary to fix minor
quirks (such as incorrect icons, especially when creating custom icons).

MacOS X works in a similar way and has its Finder has different set of
invisible information files to keep track of such things.

  #104  
Old December 16th 17, 01:40 AM posted to comp.sys.mac.system,alt.windows7.general,comp.sys.mac.apps
nospam
external usenet poster
 
Posts: 4,718
Default Can a Macintosh person tell us how to change the name of a file?

In article , Your Name
wrote:

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.


Would you care to explain, then, how the Finder knows what information
to apply to which file?


The Classic MacOS uses information stored within the Finder's own
invisible information files to understand what application to use with
each document file, the three usual ones being "Desktop DB", "Desktop
DF", and "TheVolumeSettingsFolder". These show up under Windows, which
was another cause of confusion for some users.

This is why rebuilding the database was sometimes necessary to fix
minor quirks (such as incorrect icons, especially when creating custom
icons).


somewhat correct. TheVolumeSettingsFolder was unrelated and appeared
long after classic mac os first came out.

MacOS X works in a similar way and has its Finder has different set of
invisible information files to keep track of such things.


no, mac os x definitely does not work in a similar way.
  #105  
Old December 16th 17, 02:00 AM posted to comp.sys.mac.system,alt.windows7.general,comp.sys.mac.apps
J. P. Gilliver (John)[_4_]
external usenet poster
 
Posts: 2,679
Default Can a Macintosh person tell us how to change the name of a file?

In message , Mayayana
writes:
"J. P. Gilliver (John)" wrote

| HTML email then they should see an inline image as an
| attachment. Otherwise they'll see it where you put
| it in the message. Both are base64-encoded text
| sections in the email. There's no difference in that.
|
| Nope: nothing to do with HTML. If I send a truly inline image, _in the
| middle of an email/post_, most other clients will see the image _and the
| text that follows it_ as two attachments.

If you add an inline image that is HTML. If you


No.

look at the raw code of the email you should see
the email specified as multi-part. A unique boundary
string will separate text/html/binaries. You can only


True, there will be a boundary string before and after any embedded
attachment (image or otherwise). But I can send an email that goes

text
attachment
more text

.. If I examine the raw code of the email, it'll have

(headers)
text
boundary string
encoded attachment
boundary string
more text

add an inline image in an HTML section, and that


No HTML.

image data can only go in a separate boundaried
content section.


Yes, it will be in a "separate boundaries content section". But it
_doesn't_ have to be at the end.

If you give me an email address (use a throwaway one if you're
paranoid), I'll send you an example.

I wonder if maybe this has to do with how you're
using the client software itself. In theory there's
no reason that an image can't come before text,
but it still has to be in a different content section
with a boundary, because only one type of content
goes in a section.


Yes, obviously, encoded data has to be delimited from plain text.

And I've never seen it done. In
virtually all cases, an email is done in plain text, followed
by HTML, followed by any base64-encoded files. A
plain text email would skip the HTML section.


No, I'm not talking about two-version emails, where the entire email is
repeated twice, once in plain text and once in HTML.

Maybe you're trying to put inline images in a
plain text email and the software is "humoring you"?

No, I've looked at (even edited, occasionally) the raw data form of
emails, and there's no HTML - or any other tag - in them.
______________________________
plain text with attachments
______________________________

from
to
date
subject
Message-ID
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="BOUNDARY_STRING_1"
X-Mailer: [your program name here]
#
--BOUNDARY_STRING_1
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
#
(email text here)
#
--BOUNDARY_STRING_1
Content-Type: image/jpeg;
name="earth_sm.jpg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="earth_sm.jpg"
#
(base 64 here)
#
--BOUNDARY_STRING_1--


Something like that, but my client can add more plain text after the
image.

_________________________
HTML with pictures
_________________________

from
to
subject
date
Message-ID
MIME-Version: 1.0
Content-Type: multipart/related;
boundary="BOUNDARY_STRING_1";
type="multipart/alternative"
X-Mailer: [your program name here]
#
--BOUNDARY_STRING_1
Content-Type: multipart/alternative;
boundary="BOUNDARY_STRING_2"
#
--BOUNDARY_STRING_2
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
#
(default text for non-html email readers)
#
--BOUNDARY_STRING_2
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
#
(html body here.......
IMG SRC=3D"cidic.gif"
......)
#
--BOUNDARY_STRING_2-- (end of alternative boundary.)
#
--BOUNDARY_STRING_1
Content-Type: image/gif; (or image/jpg, etc.)
name="pic.gif"
Content-Transfer-Encoding: base64
Content-ID: pic.gif
#
(base 64 here)
# (repeat for other pics if present: space, boundary,
content, space, base64, space)
--BOUNDARY_STRING_1--

Well, that's a dual-part email, since you included the plain text "for
non-html readers" as well. (I'm pretty sure I've seen emails without the
plain text version, i. e. HTML only.) I can believe that maybe HTML
messages can only have the images at the end with a pointer to them in
the text.

--
J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

If it ain't broke, don't download updates.
- Al Drake in alt.windows7.general, 2015-4-4
 




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 10:40 PM.


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