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. |
|
|
Thread Tools | Rate Thread | Display Modes |
#76
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
In article , Your Name
wrote: 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. he's right. you're not. 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). nope. many times, data files *did* have resource forks for additional information. Mainly it was only applications that had resource forks. not true, although applications usually had little to nothing in the data fork. 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. that part is true. |
Ads |
#77
|
|||
|
|||
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 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. Where "unmeasurable" means "imaginary". Lossless image compression is, in contrast, a measurable matter: To a computer? yes. To a human being, no. -- Come on. Somewhere at the edge of the bell curve is the girl for me. |
#78
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
"Lewis" wrote
| 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. 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. If it's an image it can be inline, in HTML, or sent as an attachment. That's it. Any metadata is in the attached file. There's no metadata sent in the email. |
#79
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
"Lewis" wrote
| "Lossless images" is the new "vinyl is best" idiocy. | OK. This is the last post from you that I read. You say any nonsense that comes into your head. It's *all* nonsense. At least nospam tries to be right. |
#80
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
"Tim Streater" wrote
| 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. | | Then you and / or the person to whom / from whom you send / receive | attachments are / is using a rubbish email client. | You're confusing metadata -- inside the file header -- with MIME format. Content Disposition *can* be used to send creation/modification date. I've never actually seen it done. It's certainly not required. 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. | My email client *does* send such information, and in it I also decode | such information where present and use it to update the dates for the | file. You just said it sends the data. Now you say you "decode" it. From the file header? That's not data sent in the email. I don't get this proud-to-be-ignorant Mac attitude. Not all Mac people. But it's not something one never sees among Windows users. People might not be interested in technical data, but they don't just make stuff up, pretending to be experts. There are several people here just delighted to say any old thing. No wonder you can't agree on how to open a file. |
#81
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
In article , Mayayana
wrote: I don't get this proud-to-be-ignorant Mac attitude. that's too bad, since you're *extremely* ignorant about macs and quite proud of it. Not all Mac people. But it's not something one never sees among Windows users. nonsense. plenty of windows users are incredibly ignorant. People might not be interested in technical data, but they don't just make stuff up, pretending to be experts. There are several people here just delighted to say any old thing. you being one of them. No wonder you can't agree on how to open a file. that being one such example. |
#82
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
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. but certainly up through 8 every file had to conform to 8.3 at some level. This is why you would occasionally see a filename like LONGFI~1.DOC instead of "Longfilename.docx" You're confusing the 'long' filename that humans usually use with the 'short' filename that Windows creates for its own use. There's a little more to it than that, but not much. For us humans, it's been a very long time since we were limited to 8.3 filenames. -- Char Jackson |
#83
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
On 2017-12-14 7:18 AM, 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. Ummmm... ...no. Some metadata was COPIED to the desktop database, et al. 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. |
#84
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
In message Mayayana wrote:
"Lewis" wrote | 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. You seem to just make things up on the spot. There are not "many" ways to send attachments in email. Yes there are. There's a format. All attachments are base64 encoded. No, that is not true *at all*. Any metadata is in the attached file. There's no metadata sent in the email. FSVO of metadata. The filnane (and extension) is metadata and is in the email. -- The ability to ask question like 'Where am I and who is the "I" that is asking?' is one of the things that distinguishes mankind from, say, cuttlefish. --The Last Continent |
#85
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
In message Mayayana wrote:
"Lewis" wrote | "Lossless images" is the new "vinyl is best" idiocy. | OK. This is the last post from you that I read. Excellent, the willful ignorance arena is all yours. -- Procrastination is the art of keeping up with yesterday. |
#86
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
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). but certainly up through 8 every file had to conform to 8.3 at some level. This is why you would occasionally see a filename like LONGFI~1.DOC instead of "Longfilename.docx" You're confusing the 'long' filename that humans usually use with the 'short' filename that Windows creates for its own use. I'm not confusing them at all, I am pointing out taht both still exist, and that the 8.3 name is required. There's a little more to it than that, but not much. For us humans, it's been a very long time since we were limited to 8.3 filenames. Again, reading for comprehension is your friend. "every file had to conform to 8.3 *AT SOME LEVEL*" -- Someone's behind this. Someone wants to see a war. [...] I've got to remember that. This isn't a war. This is a crime. --Jingo |
#87
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
In message , Char Jackson
writes: On Thu, 14 Dec 2017 17:24:34 -0000 (UTC), Lewis wrote: In message Paul wrote: [] 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. Long filenames came in with '95, I think. but certainly up through 8 every file had to conform to 8.3 at some level. This is why you would occasionally see a filename like LONGFI~1.DOC instead of "Longfilename.docx" You're confusing the 'long' filename that humans usually use with the 'short' filename that Windows creates for its own use. There's a little more to it than that, but not much. For us humans, it's been a very long time since we were limited to 8.3 filenames. And for the computer. Yes, the 8.3 name _is_ used internally for some functions. But for the part of the computer that uses the extension to decide what sort of file it is (e. g. what to open it with), it looks up the long name. (Strictly it isn't just "long" versus "short"; odd characters that aren't allowed in 8.3, or a long extension even if the total is less than 11 - such as a.bcde - is a "long" or at least encoded name.) -- J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf Lucy Worsley takes tea in Jane Austen's Regency Bath. - TV "Choices" listing, RT 2017-5-27 |
#88
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
In message , Lewis
writes: In message Mayayana wrote: "Lewis" wrote | 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. 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.] There's a format. All attachments are base64 encoded. No, that is not true *at all*. UUE was the other common encoding; it used to be the default, on the basis that you didn't use MIME/base64 unless you knew the recipient could decode it, but all clients could handle UUE. (Nowadays, most clients _can't_ handle UUE!) Any metadata is in the attached file. There's no metadata sent in the email. FSVO of metadata. The filnane (and extension) is metadata and is in the email. And maybe the size - and sometimes a type indicator. But in the vast majority of cases, no dates. (Interesting to read from another poster that there _is_ a mechanism for those to be included, but that he's never seen it used.) -- J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf Lucy Worsley takes tea in Jane Austen's Regency Bath. - TV "Choices" listing, RT 2017-5-27 |
#89
|
|||
|
|||
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 , 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. Where "unmeasurable" means "imaginary". That's my view too, but I try to be a bit more open-minded (or less rude if you wish). Lossless image compression is, in contrast, a measurable matter: To a computer? yes. To a human being, no. It's _extremely_ visible to me (the corruption of JPEG, I mean) if I zoom in, especially near edges between areas of large uniform colour. (Incidentally, GIF is truly lossless once you've got down to 256 colours or less - ideal for things like logos, and arguably document scans unless greyscale is being used as a substitute for resolution. Though for most purposes, I _do_ use JPEG for document scans.) -- J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf Lucy Worsley takes tea in Jane Austen's Regency Bath. - TV "Choices" listing, RT 2017-5-27 |
#90
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
"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 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. 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. |
Thread Tools | |
Display Modes | Rate This Thread |
|
|