Resfool For Mac

14 years agoUser-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.2pre) Gecko/20070111 SeaMonkey/1.1Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.2pre) Gecko/20070111 SeaMonkey/1.1When a.dwg file is attached to an email the file attachment is not done correctly by SM v1.1. If you look inside the email as in the sent folder there is an attachment but there is something wrong. The attachment does not show up when normally viewing the sent file or if sent to someone with SM v1.1 (Mac only?). When I sent an email with such an attachment to an earthlink email it got there but was shown with a name of 'unknown-0 B' and clicking on this name does nothing when an attached zip of the same file shows correctly and can be saved.Reproducible: AlwaysSteps to Reproduce:1.

AirFoil is a Mac app for streaming audio from one place to another, and it comes from Mac audio maestros Rogue Amoeba. Previously, AirFoil has let you stream non-supported apps to AirPlay.

Create a 'real'.dwg file. (A text file renamed to be a dwg works ok.)2. Create an email3. Attach the file4.

Send it.Actual Results:See summaryExpected Results:Intact file at the receiving end of the email. 14 years agoDavid sent me one of his busted messages. It has:Content-Type: multipart/appledouble;boundary='-ad0604'; x-mac-type='44574720'; x-mac-creator='41434144';name='test PC.dwg'If I attach the message myself (linux), I get:Content-Type: application/octet-stream;name='test PC.dwg'If I change David's message to use application/octet-stream, the attachment is listed OK. So, and seem related. I guess the question is why SeaMonkey is using that content type. 14 years agoI seem to be running the same SM binary as David.

I've sent his message to myself and can't reproduce his error. We need to look at more of the MIME headers than just the header for the attachment. When I send his file to myself, I get:.Subject: testContent-Type: multipart/mixed;boundary='-0604'This is a multi-part message in MIME format.-0604Content-Type: text/plain; charset=ISO-8859-1; format=flowedContent-Transfer-Encoding: 7bit-0604Content-Type: application/octet-stream; x-mac-type='54455854'; x-mac-creator='74747874';name='test PC.dwg'Content-Transfer-Encoding: base64Content-Disposition: attachment;filename='test PC.dwg'QUMxMDE1AAAAAAAGAfw.Where is appledouble coming from? Is it a function of having the app that understands DWG files installed? I would think that an unknown type would be treated as application/octet-stream by SM? 14 years ago(In reply to ) David sent me one of his busted messages. It has: Content-Type: multipart/appledouble; boundary='-ad0604'; x-mac-type='44574720'; x-mac-creator='41434144'; name='test PC.dwg'Is it wrapped like that, or is the x-mac-creator part correctly folded (indented) in the message source?

(Paste is not your friend.) I guess the question is why SeaMonkey is using that content type.answers that, does it not? David probably received a message from someone (on a Mac) sending.him. a.DWG file, with multipart/appledouble combined with application/octet-stream; he made some 'always do this' association when he opened it, and now the.DWG is associated with the multipart/appledouble.If this scenario is accurate, Tools Options Attachments, View&Edit Actions -look at the association for.DWG, and the 'multipart/appledouble' type will be associated with it. Delete that association to fix the problem seen when attaching messages.Is there a more correct MIME type for the.DWG files? Application/x-autocad or whatever?

14 years agoSome more information.This was specifically noticed when a file was sent intra-office.AutoCAD is a Windows only CAD program. They 'define' the DWG format. Sort of like MS defines the.DOC format. And they change it, usually in non trivial ways, with every new release which seems to be every two years. For better or worse most CAD programs use this format as a way to trade files. And Illustrator will open them also. So many folks who do NOT have AutoCAD use the format.This issue was NEVER seen before v1.1 so something changed.Prior to this I had two different instances of folks using a v1.1rc saying they had attached one or more files but they had not been sent and did not appear with the email in the sent folder.

But since I was told this several days after each incident I wasn't sure it was operator error. And with one of the reports that was the most likely thing to have happened. But now I don't know. And with one of the people involved it was most likely not a DWG file but another type. The likely hood of him sending anyone a DWG file is about the same as me piloting a 747. I'll see if I can track down the email in his sent folder now that I know to look for a large email that doesn't show any attachments. 14 years agoDavid, apparently I needed to express as a question, directed at you:Look in Tools Options Attachments, View&Edit Actions.

Is there an entryfor.DWG? And if you click 'Change Action', does the phrase'multipart/appledouble' appear on the little window?IF SO, delete that entry. Your problem will be solved for the near term.If not - I've just rediscovered the Mac-specific, which can cause this kind of problem without explicitly setting 'Always do this' when an attachment is opened.(In reply to ) AutoCAD is a Windows only CAD program. They 'define' the DWG format. Sort of like MS defines the.DOC format.Yes, we know; and Microsoft also registered a MIME type for the format:application/msword. I just Googled around and found that Autocad also has one: application/acadUnfortunately, Thunderbird's 'hide the MIME type so as not to confuse the users' philosophy makes it difficult to fix this problem; see. 14 years ago(In reply to ) David, apparently I needed to express as a question, directed at you: Look in Tools Options Attachments, View&Edit Actions.

I did look in the Nav helper applications of the preferences and didn't see an entry like that. If not - I've just rediscovered the Mac-specific, which can cause this kind of problem without explicitly setting 'Always do this' when an attachment is opened. (In reply to ) AutoCAD is a Windows only CAD program. They 'define' the DWG format.

Sort of like MS defines the.DOC format. Yes, we know; and Microsoft also registered a MIME type for the format: application/msword. I just Googled around and found that Autocad also has one: application/acad Unfortunately, Thunderbird's 'hide the MIME type so as not to confuse the users' philosophy makes it difficult to fix this problem; see.I'll look at these. 14 years agoI just changed the description. It's not just DWG files.

Maybe the problem is any binary file? I'm wading past my safe zone of knowledge to some degree.Architects trade all kinds of binary files all the time. If the issue is these must be defined in the MIME table (that I can't seem to find a user setting for) my clients will be hosed. I need to figure out a work around or back them down to SM v1.0.7 Asking users to.ZIP everything is NOT a good long term solution as many mail server now block all.ZIP files.

14 years ago If not - I've just rediscovered the Mac-specific, which can cause this kind of problem without explicitly setting 'Always do this' when an attachment is opened.The problem description looks like one we had a couple of years ago with Mozilla where attaching a Word.DOC file from from a Mac when using Moz on a Mac COULD (but not always) create an email with either a Null or invalid line ending. I never did figure out which. We just.ZIPed the file at the time. I'll look more closely at this one. 14 years ago(In reply to ) Uh, what version? I don't see 'Options' under the Tools menu.

Softube tsar-1 gearslutz. Luckily, things have drastically changed for the better in recent years with the release of plugins like Orilriver, Dragonfly Reverb, MuVerb, Cloud Seed, and others.We now have a range of excellent free reverb effects to choose from, from go-to mix reverbs which can handle most mixing situations to more specialized plugins that are intended for sound design purposes.

SM v1.1Sorry; I'm using Thunderbird. On the suite, we're talking aboutPreferences Navigator Helper ApplicationsAnd on the suite, the item in question won't be listed under 'DWG' but (probably) under 'multipart/appledouble'. Select it and click Remove.(In reply to ) Architects trade all kinds of binary files all the time. If the issue is these must be defined in the MIME table (that I can't seem to find a user setting for) my clients will be hosed.Well: I'm pretty sure that you're seeing some combination of and, maybe,; if so, then editing the MIME table may be required. Fortunately, it's much easier to do that under the suite. For instance: at the Helper Apps dialog, after you delete the multipart/appledouble entry, select: New Type. Fill in the fields as follows:MIME Type: application/acadDescription: AutoCAD Drawing FileExtension: DWGPlus, select your preferred action, and OK.

Now you're ready to go; DWG files that you receive will be handled as you expect, they won't change the MIME table, and when you send out a.DWG file, it will go out with the correct application/acad MIME type associated with it. 14 years ago(In reply to ) (In reply to ) Uh, what version? I don't see 'Options' under the Tools menu.

SM v1.1 Sorry; I'm using Thunderbird. On the suite, we're talking about Preferences Navigator Helper Applications And on the suite, the item in question won't be listed under 'DWG' but (probably) under 'multipart/appledouble'. Select it and click Remove.No such entry. I even looked in the file 'mimeTypes.rdf' and can't find anything close.What I do have, as best I can tell from the mimeTypes.rdf file, is. 14 years ago(In reply to ) (In reply to ) (In reply to ) Architects trade all kinds of binary files all the time. If the issue is these must be defined in the MIME table (that I can't seem to find a user setting for) my clients will be hosed.

Well: I'm pretty sure that you're seeing some combination of and, maybe,; if so, then editing the MIME table may be required. Fortunately, it's much easier to do that under the suite. For instance: at the Helper Apps dialog, after you delete the multipart/appledouble entry, select: New Type. Fill in the fields as follows: MIME Type: application/acad Description: AutoCAD Drawing File Extension: DWG Plus, select your preferred action, and OK. Now you're ready to go; DWG files that you receive will be handled as you expect, they won't change the MIME table, and when you send out a.DWG file, it will go out with the correct application/acad MIME type associated with it.I wasn't clear.

It would be almost impossible for me to get a list of all file types. Kind of like asking folks to name every thing they ate in the last month. DWG was just the one that hit first.

The day after I put in SM v1.1. 14 years ago(In reply to ) And on the suite, the item in question won't be listed under 'DWG' but (probably) under 'multipart/appledouble'.

Select it and click Remove. No such entry. I even looked in the file 'mimeTypes.rdf' and can't find anything close.Well, that's a drag. Could you send me a message with a DWG attachment, created the same way as the original report?(In reply to ) I wasn't clear.

It would be almost impossible for me to get a list of all file types.You were perfectly clear. I was providing a workaround. Could you at least try it for that DWG file type, to see if it works? Since my original assumption has been shown incorrect, I'm not even sure the workaround will do the trick. 14 years ago(In reply to ) Well: I'm pretty sure that you're seeing some combination of and, maybe,; if so, then editing the MIME table may be required.

Fortunately, it's much easier to do that under the suite. For instance: at the Helper Apps dialog, after you delete the multipart/appledouble entry, select: New Type. Fill in the fields as follows: MIME Type: application/acad Description: AutoCAD Drawing File Extension: DWG Plus, select your preferred action, and OK.

Now you're ready to go; DWG files that you receive will be handled as you expect, they won't change the MIME table, and when you send out a.DWG file, it will go out with the correct application/acad MIME type associated with it.Did the above. DWG file got through. Appears to be ok. 14 years agoOh, good.

Now you've fixed it, so that means it's going to Even More Difficult for you to send the information I asked for. I don't want ZIP files.

I didn't really want the mimeTypes.rdf, altho I can verify that it doesn't exhibit the problem I was originally assuming.I want an actual, as-sent, broken email message of the type you were complaining about in the first place. That's why I said, in, Could you send me a message with a DWG attachment, created the same way as the original report?. 14 years agoExcuse me.From a machine with nothing changed in the profile I sent TWO emails. One with a.zip of two different files that seem to break things plus a copy of my mime/types in case it would be useful.THE SECOND email has the.zip plus the two file inside the zip independently. I was trying to send as much as possible. I guess I was wrong. Anyway the second email breaks in multiple ways from the user point of view.

You can't even see the.zip file that was attached first.WHAT I FIXED was on my personal machine. To see, as I thought you wanted me to, if adding the DWG mime type, would fix things. On my personal machine.Tell me what do do next to help and I will. I thought I was. I'll read more carefully in the future. Attached file— THE SECOND email has the.zip plus the two file inside the zip independently. Anyway the second email breaks in multiple ways from the user point of view.

You can't even see the.zip file that was attached first.Here's the message in question. When I received it, the.zip attachment was visible and seemed to be the only attachment in the message. When I viewed the message source I didn't notice the other attachment, which was completely empty except for the headers.The MIME structure of this message is as follows:Top: multipart-mixed; boundary=xxx902-xxx902Part 1: text/plain OK-xxx902Part 2: application/zip OK-xxx902Part 3: multipart/appledouble; name=BlankPowerCADD.dwg; boundary=yyy704-yyy704Part 3.1: multipart/appledouble; name=BlankPowerCADD; boundary=zzz702-yyy704-xxx902-Both part 3 and 3.1 are empty, except for the headers. Since these are supposed to be three separate attachments, it's not clear why part 3.1 is nested within part 3. 14 years agoFirst, let me clarify my. I sent David's attachment, (not the entire.eml) to myself.I downloaded the attachment from #20, and saved it as a.eml.

When I opened it, it just displayed the text part, no sign of the attached.dwg file. I then went and edited out the -yy503- boundary mentioned in #20. No difference when I tried to open it. I then put the trailing 503 boundary back and added a leading -yy503 (note trailing - removed) boundary. Still no difference. I'm going to have to crack the books on MIME.

I don't know whether the boundary is supposed to go within the encoded data or outside. Logically, it should go within, since the parts have to be separable? The error may be the trailing boundary not being included with the encoded data? (I need to dig up a free-standing base64 decoder.)David, you've sent us busted samples. How about sending me a non-busted sample of the same attachment, presumably from a 1.0.6/7 OS X SM? I presume the others will want to be copied too.I'm curious about interoperability here.

Does it alway occur when the sender is a SM 1.1? Does it matter what the receiver is SM 1.1, 1.0.x, Mac, Win? Etc.I'm also new enough to Mac to not understand resource forks, but I wonder if resource forks cause appledouble to be used?

If I just pull down a.dwg onto my system, will it have a resource fork? If it doesn't, is that why it is sent application/octet-stream? Where I'm driving is can this be trivially reproduced for any Mac file with a resource fork? (How can I view a file's resource fork?). 14 years ago(In reply to )Things I can respond to before I head for the vet. David, you've sent us busted samples.

How about sending me a non-busted sample of the same attachment, presumably from a 1.0.6/7 OS X SM? I presume the others will want to be copied too.Everyone on this bug? I'm curious about interoperability here. Does it alway occur when the sender is a SM 1.1? Does it matter what the receiver is SM 1.1, 1.0.x, Mac, Win? Etc.So far I've not tried it on anything but SM v1.1 on a Mac. It first surfaced when outsiders mentioned that attachments they were expecting were missing.

Mostly Windows, mostly not any Moz product. It started when I switch the staff from SM v1.0.x to v1.1. It happens during the creation / sending as the copy in the Sent folder is bad. I'm also new enough to Mac to not understand resource forks, but I wonder if resource forks cause appledouble to be used?

If I just pull down a.dwg onto my system, will it have a resource fork? If it doesn't, is that why it is sent application/octet-stream? Where I'm driving is can this be trivially reproduced for any Mac file with a resource fork?I'm not a wizard on this subject but here's what I think I know.

The latest version of Fuugo TV for DVB-T is 2.3 on Mac Informer. It is a perfect match for Streaming Media in the Audio & Video category. The app is developed by Axel Technologies. Our website provides a free download of Fuugo TV for DVB-T 2.3 for Mac. The Fuugo TV for DVB-T installer is commonly called containerforfuugotvfordvb-t1.6.zip. The actual developer of this software for Mac is Axel Technologies. The most popular version among the program users is 1.6. The software is included in Audio & Video Tools. Fuugo tv for dvb t free version download for mac.

Resource forks are a separate data stream for the file. It is structured. On OS X 10.4.x you can have more streams. Few if anyone uses them.

Resource forks are 'depreciated' according to Apple which means you should stop using them. But this and the multiple data streams in a file seem to be a continous point inside of Apple and not everyone seems to agree with this path.Anyway, the newer file formats from Apple usually do not have a resource fork.

But many do have small ones. To do simple testing you can take a text file (notpad say) from a Windows setup and move it to a mac.

It will NOT have a resource forks. Open it will Resfool (see below) and you'll get a chance to create a resource fork for the file.I can't remember a trivial way to see if a file has a resource fork just now other than copying it to a FATxx device. Say a memory stick. But to see the fork you'd have to take the stick to a Windows machine or look at it via terminal as the Finder 'hides' such things from you. (How can I view a file's resource fork?)Resfool$20 shareware but it will work for a week or so before the NAG gets real annoying.

If you want others visit and search for resedit.Now this may (but I doubt it) be only an issue with HFS+ file systems. All the systems I work with use this and this is what I'll bet 99% of the Macs out there use. Resource forks are built into HFS+. On FATxx and some other systems they exist as a separate file. On NTFS I think they use built in features of the file system. 14 years ago(In reply to ) (In reply to ) David, you've sent us busted samples. How about sending me a non-busted sample of the same attachment, presumably from a 1.0.6/7 OS X SM?

I presume the others will want to be copied too. Everyone on this bug?Well, I was thinking anyone you'd previously sent a sample to + me, but perhaps me and Mike will do. We should get an unbroken one attached to this bug for comparison, but I'd like to receive one 'live'.Can't do more until maybe this evening.:/. 14 years ago(In reply to ) First, let me clarify my.

I sent David's attachment, (not the entire.eml) to myself.Right. And once I saw David's actual problem message, I should have confirmed this bug, because what you posted shows the same problem: the headers are broken. I don't know what's causing it, tho, and I can't reproduce it since I don't have a Mac.The problem is, the MIME in the outgoing message is invalid. It's Mozilla's fault.It's interesting to me that the workaround of manually assigning a useful MIME type to the particular extension does in fact fix the problem; but David is right that this is not a solution generally. David, you've sent us busted samples.That was the whole point - without a broken message, how can we begin to analyze what the problem is? The thing is, I don't have a Mac, which is how appledouble attachments are generated.

How about sending me a non-busted sample of the same attachment, presumably from a 1.0.6/7 OS X SM? I presume the others will want to be copied too.has an attachment which is a message with (I believe) a valid appledouble attachment, if you want to see an example. 14 years ago(In reply to ) It's interesting to me that the workaround of manually assigning a useful MIME type to the particular extension does in fact fix the problem; but David is right that this is not a solution generally.says2c. Detail specific to MIME-based usageMacintosh documents do not always need to be sent in a specialformat. Those documents with well-known MIME types andnon-existent or trivial resource forks can be sent as regularMIME body parts, without use of AppleSingle or AppleDouble.That matches the behavior we see.I sent myself the HelloWorld sample file from Apple's Mail.app andI got a file with the same structure as David's 1.0.7 transmission.Aside 1: Mail.app included x-unix-mode=0644; on the content-typeof the actual data part.Aside 2: Mail.app offers a 'Send Windows Friendly Attachments'checkbox in the Attach dialog.

When I tested with that, it sentthe HelloWorld file as a simple attachment of type application/octet-stream. Good Idea (s/Windows/Non-Mac/). 14 years ago(In reply to ) With all the research that's gone into this problem, does someone have concise steps for reproducing this problem, along with a sample file to attach? I do have a mac to try this on.As best it seems from the work done here, if you attach a file to an email and that file HAS a resource fork and DOES NOT have a stored mime/type the problem will occur. The problem is that the attachments are not correctly encoded into the email.Getting a file with a resource fork isn't always obvious as the Finder goes out of the way to hide this from you. If you have a resediting tool, it will tell you if a file has a resource fork.

Most tools will allow your to create a resource fork for a file if one is not present. ResFool, mentioned above will allow you to do this. 13 years agoWFM, Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.2pre) Gecko/20070111 SeaMonkey/1.1:-)I sent my HelloWorld attachment to David, let's see if he gets fixed for it and his.dwg files.Might I suggest that for posterity's sake, this bug be renamed to something like 'OS X files with resource forks and no defined MIME type encoded incorrectly' since it was found to not be.DWG specific.FYI, I located a free resource fork editor, Rezilla (oooo, catchy name!) at. This one is freeware. Didn't mess with it though.