borton@sdcc3.UUCP (Chris Borton) (01/30/86)
I have had several files recently show up on my Desktop with their "File
Busy" bits set. (usually from an aborted file transfer) So far I have been
unsuccessful in clearing them, and the Finder refuses to delete them. Finder
4.1 would pretend to delete them, but they would reappear later; 5.0 said
'Couldn't empty trash' and would go into a loop of that when you hit OK;
Finder 5.1 says it couldn't empty the trash and they reappear later.
ResEdit 0.8 allows you to uncheck that bit from the Get Info box, but has no
effect. ResEdit 1.0 D4 won't allow you to uncheck the box. Both pretend to
delete the file when the file is chosen and Cleared, but actually don't.
This is on the root directory of my HD20, so I'm more limited in the tricks
and programs (disk utilities) I can use. MacTools didn't see the file.
Fedit 3.0 wasn't any help.
How can I set/clear the File Busy bit? How can I delete this file?
Thanks for any help...
--Chris
---------------
Chris Borton, UC San Diego Undergraduate CS
Micro Consultant, UCSD
borton@ucsd.ARPA or ...!{ucbvax,decvax,noscvax,ihnp4,bang}!sdcsvax!bortonjoel@gould9.UUCP (Joel West) (01/31/86)
If you look at the MacUser they gave away at the MWE, it has 86 tips on how to be a 'power user'. The one that was news to me, was: Touch a file, any busy file. Hold down option and drag it into the trash. Shazzam! It's gone. Real useful when MDS edit crashed and leaves a busy clipboard.
phil@sivax.UUCP (Phil Hunt) (01/31/86)
> I have had several files recently show up on my Desktop with their "File > Busy" bits set. (usually from an aborted file transfer) So far I have been > unsuccessful in clearing them, and the Finder refuses to delete them. Finder > 4.1 would pretend to delete them, but they would reappear later; 5.0 said > 'Couldn't empty trash' and would go into a loop of that when you hit OK; > Finder 5.1 says it couldn't empty the trash and they reappear later. > > ResEdit 0.8 allows you to uncheck that bit from the Get Info box, but has no > effect. ResEdit 1.0 D4 won't allow you to uncheck the box. Both pretend to > delete the file when the file is chosen and Cleared, but actually don't. > This is on the root directory of my HD20, so I'm more limited in the tricks > and programs (disk utilities) I can use. MacTools didn't see the file. > Fedit 3.0 wasn't any help. > > How can I set/clear the File Busy bit? How can I delete this file? > > Thanks for any help... > > --Chris > --------------- > Chris Borton, UC San Diego Undergraduate CS > Micro Consultant, UCSD > > borton@ucsd.ARPA or ...!{ucbvax,decvax,noscvax,ihnp4,bang}!sdcsvax!borton on a floppy, you drag the disk to the trash and then after it ejects, put it back in the drive when you put it back in, it remounts and the bits are off!! I found this out using MS Fortran, when it dies on a disk full error leaving 6 or 7 bad temp files out there that could not be deleted. *** REPLACE THIS LINE WITH YOUR MESSAGE ***
roman@sigma.UUCP (Bill Roman) (02/02/86)
I haven't tried with Finder 5.x or HFS, but with Finder 4.1 (and
earlier) and MFS, command-option-drag to trash seems to work for
throwing away "busy" files.
--
Bill Roman {ihnp4,decvax,allegra,...}!uw-beaver!tikal!sigma!roman
Summation, Inc.
18702 142nd Ave NE
Woodinville, WA 98072
(206) 486-0991borton@sdcc3.UUCP (Chris Borton) (02/03/86)
Thank you to all the people that sent replies on how to clear the "File Busy"
bit. The consensus was to drag it to the trash can with BOTH the option and
the command keys down. (I had tried option but not both) The operation was
successful.
It brings up a different question, though, about why ResEd pretended to clear
the bit in 0.8 (and didn't actually) and wouldn't allow it in 1.0 D4. Both
versions pretended to delete the file but didn't actually. Is the "File
Busy" bit so sacred that even the hacker's ResEd can't touch it? While the
Finder merrily ignores it given the correct keys? (Where is that documented,
anyway?)
Any ideas?
--Chris
--------------
Chris Borton, UC San Diego Undergraduate CS
Micro Consultant, UCSD
borton@ucsd.ARPA or ...!{ucbvax,decvax,noscvax,ihnp4,bang}!sdcsvax!bortonguido@boring.UUCP (02/04/86)
So far I've seen only descriptions of (sometimes failing) ways of tricking various Finders into throwing away locked files in response to this problem. What *may* be the case here is something quite different from files with the lock bit on: files that are still 'open'. I don't know what file transfer program you were using, but it may be the case that when a transfer fails it doesn't properly close the file. Unlike real operating systems like UNIX (forgive the flame), the Mac doesn't close open files when an application exits. And open files can't be deleted. Since the file system's error code in this case is the same as for files with the lock bit set (I believe), the error message will almost undoubtedly be unclear about this possibility. Even the Finder can't cheat the file system here; it may clear the lock bit when you press option while dragging to the trash, but it can't close the file since it doesn't know the handle (knowledge about it vanished when the application that opened it exited [see footnote]). The only immediate cure is to reboot; to prevent the problem in the future you should get your file transfer program fixed. (If rebooting doesn't make the file removable again, my guess at the problem's cause above is wrong!) __________ Footnote: in fact it would possible to close such a file: the PBGetFInfo call returns the first handle to a file when it is open. However, I can see good reasons why the Finder should not try to mess with this, even when the user overrides normal protections (such as open DA's and running under the Switcher). Also, the problem is really with the application that failed to close the file (or with the design of the operating system :-). -- Guido van Rossum, CWI, Amsterdam (guido@mcvax.UUCP)
berry@tolerant.UUCP (David Berry) (02/06/86)
> It brings up a different question, though, about why ResEd pretended to clear > the bit in 0.8 (and didn't actually) and wouldn't allow it in 1.0 D4. Both > versions pretended to delete the file but didn't actually. Is the "File > Busy" bit so sacred that even the hacker's ResEd can't touch it? While the > Finder merrily ignores it given the correct keys? (Where is that documented, > anyway?) Something that I have discovered quite recently is that the PBSetInfo trap doesn't change the file flags portion of the information structure. It only affects the creation date, modification date, and Finder information structure. The busy bit is actually a bit in the file flags word and therefore can't be changed short of actually changing the actual disk block. -- David W. Berry dwb@well.UUCP Delphi: dwb {ucbvax,pyramid,idsvax,bene,oliveb}!tolerant!berry I'm only here for the beer.