Frigging fricking ._files!

Posted:
in macOS edited January 2014
Hi there, anyone know if there's a way to prevent OS X from creating the annoying resourcefork-files (._filename) when you're connecting to non-HFS disks, for example over a windows network?



I use BBEdit to open and edit Asp-files on a remote disk, and every time I save a file it creates an (empty!) ._file for it. Is this a problem with BBEdit or is it OS X that creates the files regardless of the presence of a resource fork?



Thanks in advance..

Comments

  • Reply 1 of 17
    Blame BBEdit.



    The ._filenames should ONLY be created for files that contain a resource fork. Apparently, BBEdit is adding resource forks to all of its files regardless of if it contains any data.
  • Reply 2 of 17
    ;(



    Thanks for the info..
  • Reply 3 of 17
    kickahakickaha Posts: 8,760member
    Yup, that's BBEdit... it adds information like where the cursor last was, what the window size was, etc, etc. so the next time you open the file, it's *exactly* where you left it last time you edited.



    Look for a preference in BBEdit (don't use it, can't point you to it, sorry) for turning off the rememberance of such things.
  • Reply 4 of 17
    ringoringo Posts: 328member
    In the BBEdit prefs, go to "State" and select "none" and uncheck "Always add state".



    You can then delete all the ._* files and never see them again.
  • Reply 5 of 17
    Ok, I tried that and it didn't work.



    I've unchecked "honor saved state" as well as all the settings that get greyed out by that one, selected "none" as default state and unchecked "always add state". BBEdit still creates ._ files...



    Thanks for the tips though.



    [ 11-05-2002: Message edited by: Whyatt Thrash ]</p>
  • Reply 6 of 17
    On the Windows/Mac network I have setup at work, OS X creates ._insertfilenamehere files for pretty much every file that is copied to the windows drive from the mac while using the mac. Copying files from the Mac to the PC using the PC this does not happen (which I don't expect to happen) and copying files from the PC to the Mac using the Mac this doesnt happen that I've noticed.



    So I think OS X is the culprit, would it not seem that way anyway?



    --PB
  • Reply 7 of 17
    kickahakickaha Posts: 8,760member
    More like a misunderstanding of what's going on where, and when. :/



    Mac -&gt; PC, while on Mac.



    The Mac copies the files over, and *if it already has a resource fork*, copies that over as a ._ file.



    Mac -&gt; PC, while on PC.



    The PC copies *just the data fork*, since it knows nothing about the resource fork. Net result? Lost resource forks.



    PC -&gt; Mac, while on Mac.



    The PC files *don't have resource forks*, so there's nothing *but* data forks to copy.



    Note that the only time you'll end up with ._ files is when you're on the Mac, and moving files from the Mac to a PC... *AND THEN* only if the file already has a resource fork.



    If the file has a resource fork, would you rather MacOS X just toss that information out the window when copying to a PC? ("Well, you don't need that info on a PC!" you say... but what happens when you copy it to another Mac then?)



    The solution to minimizing ._ files is to see what apps are creating these offensive files in the first place, and find out if there's a way to have them be saved as resource-free. Graphic Converter, for instance, has a 'Web Ready' option for saving files without a resource fork.
  • Reply 8 of 17
    der kopfder kopf Posts: 2,275member
    Don't care what you say about it, I was copying onto a server from my powerbook in the comp sci dept. last year, closely watched by my mentor, and it was f*cking embarassing to see the new rock stable unix os do something so stupid.
  • Reply 9 of 17
    [quote]Originally posted by der Kopf:

    <strong>it was f*cking embarassing to see the new rock stable unix os do something so stupid.</strong><hr></blockquote>Do you have any idea what you're you talking about?



    It is a GOOD THING that Mac OS X does this. Would you rather the system just arbitrarily delete some possibly critical pieces of your data when copying to a different file system?



    Uhh, right.



    Heaven forbit the data be conveniently stored in a file named so that is would be invisible on most file browsers...
  • Reply 10 of 17
    [quote]Originally posted by Brad:

    <strong>

    Heaven forbit the data be conveniently stored in a file named so that is would be invisible on most file browsers...</strong><hr></blockquote>



    hmm... Then... How is the data-bit for making a file hidden stored on NTFS? Why not make these files invisible in both Unix and Windows environments?



    Ideally apps wouldn't create these files unnecessarily (seriously, why would a html-file need a resource fork?) but making them invisible not onle on the Mac would at least be a semi-viable solution...



    Just a thought.



    P.S Any help on the BBEdit issue?
  • Reply 11 of 17
    der kopfder kopf Posts: 2,275member
    [quote]Originally posted by Brad:

    <strong>Do you have any idea what you're you talking about?

    </strong><hr></blockquote>



    Look here, if I phrase my comment as such, then I voice the disappointment of a real mac user. I was copying these files to be used by a php script on a webserver (under linux something, I believe), and because of this quirky behaviour, the script turned out a good deal of gobbledygook. It took us a good while to find out that mister Mac was the (conveniently silent) spoily brat.



    Now, I do not know to what extent the metadata proposal of those people over at macintouch had effect (or what it was truly about even, I admit), but I am sure that THIS was surely a thing they did want to see leave the os.



    I mean come on, even if these silent files do serve a good purpose on my mac, they are useless on a windows and the likes. Even this .DS-store, or whatever it's called. It is truly annoying the fine crappers out of me.



    It's like over at apple, they can't make up their minds: file to app binding through the file extension (imagine the uproar if Apple'd have introduced this in the beginning of the nineties - if you are old enough).

    metadata in poorly hidden files (which, moreover, get corrupted on a regular basis leaving your average, uninsightful and non-terminal-fähig mac user completely puzzled). So, to answer your question:



    [quote] Would you rather the system just arbitrarily delete some possibly critical pieces of your data when copying to a different file system? <hr></blockquote>



    Yes, I would, or even better, I'd like an OS that's able to make up it's mind. That's either smart enough to correctly handle it's metadata in this thoroughly networked interOS world, or that disposes of it completely. THAT's what it would like.
  • Reply 12 of 17
    [quote]I mean come on, even if these silent files do serve a good purpose on my mac, they are useless on a windows and the likes. Even this .DS-store, or whatever it's called. It is truly annoying the fine crappers out of me.<hr></blockquote>You still don't get it.



    The dot files don't just store metadata -- they store *actual* data! Specifically, they store the resource fork of their corresponding files. Wouldn't it be just lovely to copy a font or a picture or a program or something to another filesystem only to find that the file is half gone or completely empty? Oh sure, no big loss there at all. <img src="graemlins/bugeye.gif" border="0" alt="[Skeptical]" />

    [quote]It's like over at apple, they can't make up their minds: file to app binding through the file extension (imagine the uproar if Apple'd have introduced this in the beginning of the nineties - if you are old enough).<hr></blockquote>Would you rather have file content just disappear altogether when moving to another file system? Would you rather have all your files come back as "unknown" documents, giving the OS no idea what kind they are or how to open them? When working in a cross-platform world, you have to find a way to keep this important data. That's why we have the dot files.



    It's not perfect, but it's far better than how Classic Mac OS handled it (that is, by just deleting the data altogether).



    Should there be a more elegant solution? Of course. Can you just develop one overnight? Uhh, no. If you've read any of the various threads or articles on future filesystems and forks and metadata, you'll know that a LOT of things have to be considered before developing a solution. I'd much rather have to put up with these dot files until a better system is made instead of just losing my data altogether.

    [quote]metadata in poorly hidden files (which, moreover, get corrupted on a regular basis leaving your average, uninsightful and non-terminal-fähig mac user completely puzzled).<hr></blockquote> I have NEVER seen metadata or dot files become corrupted or broken under regular use. I honestly don't know what you're talking about here.

    [quote]Yes, I would, or even better, I'd like an OS that's able to make up it's mind. That's either smart enough to correctly handle it's metadata in this thoroughly networked interOS world, or that disposes of it completely. THAT's what it would like.<hr></blockquote>Again, I'm at a loss. You want an OS that makes up its mind? Uhh, what does it need to "make up its mind" about?



    [ 11-08-2002: Message edited by: Brad ]</p>
  • Reply 13 of 17
    der kopfder kopf Posts: 2,275member
    [quote]Originally posted by Brad:

    <strong>I have NEVER seen metadata or dot files become corrupted or broken under regular use. I honestly don't know what you're talking about here.

    </strong><hr></blockquote>



    I'm talking about the case where a folder gets thoroughly mangled for some reason. Either in that your display choice doesn't stick, or that your finder just plain crashes when, for example, you choose to view the contents of a folder in list view, or even, in a worst case, that you can't see completely legit files that you know are in a folder (files which you have to go dig in the terminal to retrieve them). That's metadata corruption, and I seem to get some on a regular basis.



    As for your other remarks, I admit that things aren't as easy as they appear, and that an uninsightful remark (and unconsidering as to the developers) is not only gratuitious but also a pain in many a developer's ass, but still, I just feel that this OS shouldn't do it. The case I stated before you is, as you can surely judge, a fairly real problem, and there isn't that many documentation describing this over at apple, so it really does become puzzling at times.

    Of course, if you'd ask me, I'd think that the actual data of a file should be stored in that file, but I may be wrong. Anyway, could you tell me WHAT then is stored in the myriad ._ files?



    [quote]Originally posted by Brad:

    <strong>

    Again, I'm at a loss. You want an OS that makes up its mind? Uhh, what does it need to "make up its mind" about?

    </strong><hr></blockquote>



    As I understand, early DOS and windows chose the path of extensions to determine the behaviour of a file, so all was in the name of the file.

    Mac os on the other hand did this in a for the user, invisible (yet relatively infallible) way for the user (and one of the reason, I reckon, for the mac's user friendliness).

    Now OS X seems to determine the behaviour of files through a cocktail of the above method. (e.g. files with different extensions may be set to open with different apps, but deleting the extensions of a file very frequently makes your file a ghost for your system - in that the system doesn't know how to treat it).

    This now, in my eyes, looks like the OS is puzzled as to whether choice is better, and therefor chooses the worst middle passage.

    (of course the OS is not puzzled 'as such' - that is merely my wording).
  • Reply 14 of 17
    I'm just a bit confused as to the real functionality of this.. If I mount a foreign drive, why would I want to store files with resource forks on it anyways? If I put a file with a resource fork in it on a PC, the PC user that I share it with wouln't be able to read it anyways. The only use I see for it is if I have an internal disk or if the foreign disk is a storage/backup device. I wouldn't put a file on a PC to share it with other Mac-users.



    This should be an option. The .DS_Store-file doesn't really bother me, there's only one per folder. the ._ files end up being quite a lot though.



    Just a short rant. Pay no heed.
  • Reply 15 of 17
    And while we're yapping away about the resource files, I decided to conduct a little experiment. I took one of the files that has a corresponding ._file under NTFS and tried opening the file using ResEdit, as well as a copy of the ._file copied using the terminal. Guess the result.



    "This file has no resource fork. Opening it will add one. Do you wish to open it?"



    So there.. Quit blaming BBEdit..
  • Reply 16 of 17
    kickahakickaha Posts: 8,760member
    [quote]Originally posted by Whyatt Thrash:

    <strong>ResEdit</strong><hr></blockquote>



    Well jeez mon, what did you expect?!? It edits *RESOURCES*!



    We're not blaming JUST BBEdit... ANY app that adds resource forks will cause a ._ file to be made when it is transferred to a non-HFS filesystem.



    The more intelligent apps let you make files without resource forks, like GraphicConverter.



    The less intelligent apps insist on adding a resource fork all the time.
  • Reply 17 of 17
    der kopfder kopf Posts: 2,275member
    oh yes, and if you really want, you can use the nifty app resourcedropper, which simply removes the resource fork of files, leaving only the data fork.



    The use of the app is especially noticeable in images, which still carry OS 9 -icons and previews (these have become, with the Jag generating them on the fly, useless): I downsized a folder of 5000 images from 600 MB to just about 400 MB with the dropper app.
Sign In or Register to comment.