MacFileOperationStatusMBS Error Codes

Add-Ons
1

I’m using MacFileOperationMBS and associated MacFileOperationStatusMBS to copy and move files asynchronously.

Occasionally MacFIleOperationStatus shows an error number 104. My (old) code suggests that I found the cause to be file in use (I think from the older Folderitem.lastErrorCode documentation) - but I can no longer find the same reference to that error number.

New searches suggest the error is something to do with sNeedToWriteBootBlocks = 104, /need to write new boot blocks/, but I’m not sure I’m looking at the right set of error codes.

Does anyone know which error codes I should be looking at to resolve this problem, specifically for error 104? I’ve tried Krypted, Developer.Apple, MacWizard…

2

Well, where exactly do you have error 104?
In Lasterror property of folderitem or last error property of MacFileOperationStatusMBS class?

3

In MacFIleOperationStatusMBS.error

4

Anything in the dictionary?
Oh, that’s missing, so let me make it available for next prerelease.

5

Thank you - that will help.

6

Anyway, please check what the reason may be.
The error 104 is in MacErrors.h:

 dsNeedToWriteBootBlocks       = 104,  /*need to write new boot blocks*/
7

Any idea what that means in context of trying to copy or move a file?

8

NO. This is probably wrong list of error codes.

9

Christian - I have loaded the dictionary but it just lists the same stuff as in the properties - eg bytesRemaining etc. Nothing there about error codes. Am I missing something else?

10

Sorry, you are missing nothing.

I hoped some more details would be there.

You can only try to find the reason to get a clue.

11

Or run the app in terminal and see whether a log message is printed.

12

You’re right: 104 is also a code Xojo maps to when a file is in use. I wouldn’t expect this 104 instance to come from there, as the MacFileOperation doesn’t use the Xojo framework.
Also, I can hardly find these mapped error codes in Xojo these days, too. I even think I had to search for them in an earlier Xojo version, tired of not finding them anymore. That’s strange, as they are still widely used…

Mac OS and the reuse of same error codes for different frameworks… a nightmare, I’d say.

At https://osstatus.com, 104 errors list reveals some more possible reasons. Would one fit your case?

13

Mmm, tried those but none seemed to make any sense.

14

It doesn’t make sense to me to get a Xojo error code from a MacOS framework.

15

Yes, I’m almost sure it’s not a Xojo error code.
If it was taken from a FolderItem, it would have made sense, but not here.

In cases like this, where the error code doesn’t make much sense, another approach is to “guess” what’s wrong with the file or folder (source, destination). First, look at the properties in Xojo. Anything you may not have expected (even, say, a creation date that is nil, which shouldn’t be) may give a clue.
Then, play with the file. Open it in an editor, copy it somewhere else; try to put another file (e.g. with the same name) in the destination folder to see if that folder accepts a file with that name, etc. If you encounter errors outside of Xojo, you may at least track whether this problem comes from Xojo or the OS.
Often, odd file systems behaviours can be tracked by examining related objects (the source file/folder, the destination, their contents, the Volume (check in Disk Utility)). It may take, e.g., one day, at most, to get on the right track, but then (1) you know things deeper, like how a file system may behave under unexpected situations and (2) you can avoid such similar behaviours in your own code, should they happen to another user with the same configuration, by adding checks. If you can’t manage to find anything after some times, it’s up to you to continue if you’re curious enough (I am and I like it).

16

I have been doing some more checking on these codes - right now I am getting -47 and -48 codes in certain circumstances:

  1. When using MacFileOperationMBS to Move files to or from a USB magnetic drive to any other drive.
  2. When the file in question has been opened as a movie within Movie player.

When I get the code - the file in question has been copied, but not moved from its original location.

In other circumstances - e.g. when moving between others drives (eg SSDs, NAS etc) or when not opening the file within Movie player I don’t get the codes returned and the file is moved correctly.

I have a pared down example project here: but can’t tell if this is:
i) a magnetic drive problem (other users report the same problem with USB magnetic drives)
ii) a MacFileOperationMBS problem or
iii) a MoviePlayer problem.

Can anyone point me in the right direction?

17

Ok. Error -47 means a file can’t be deleted because it’s in use (e.g. open somewhere). -48 means there’s already an item with this name (either when copying/moving something: an item having the same name is already in the destination folder, or when renaming: the user/app tried to change the file name to something already taken in the same parent folder).

Have you already discovered what results in -47 rather than -48 (and the other way around) in your code? It looks like you’re trying a lot of combinations and it’s hard to link the errors you get with each attempt.

I’d not expect a -47 error code in Mac OS: when a file is deleted but still in use, the delete call usually returns no error; the file would vanish from disk when it’s closed later everywhere.
If you move items across different volumes, the OS copies the items and then would delete the original ones. The -47 error can happen at the 2nd step (removing the original ones, especially when the items are in use).
Tip: in Mac OS, use the “lsof ” terminal command to see what app keeps a file open.

-48 almost mean you already have an item with the same name in the destination. It can be indirect: an empty name or a path can “already exist”.
HTH

18

@Arnaud Nicolet Have you already discovered what results in -47
I’m not sure because it occurs in different situations. But yes, it is the 2nd step in the Move between different volumes as you explain. Examples:

  1. Get file from magnetic drive, movie.open(file), MacFileOperation.move(file) = causes -47.
  2. Get file from SSD, movie.open(file), MacFileOperation.move(file) = no error.
  3. Get file from magnetic drive, MacFileOperation.move(file) = no error.

So it seems to be only the combination of moving a file to/from a magnetic drive and showing the movie in movieplayer that causes the problem.

I have only seen -48 once, and haven’t had chance to analyse but your explanation is possible.

There aren’t any other apps using the same files to make it open anywhere else.

19

Yes, this happens when a file is in use and Mac OS asks for its removal (trying to unmount its parent volume, attempting to delete the file (by any means: plain deletion, emptying the trash or, for a move across volumes, after the file has been copied)).
Frankly, I saw this error way more often in the past.

[quote=496763:@James Pitchford]I’m not sure because it occurs in different situations. But yes, it is the 2nd step in the Move between different volumes as you explain. Examples:

  1. Get file from magnetic drive, movie.open(file), MacFileOperation.move(file) = causes -47.
  2. Get file from SSD, movie.open(file), MacFileOperation.move(file) = no error.
  3. Get file from magnetic drive, MacFileOperation.move(file) = no error.

So it seems to be only the combination of moving a file to/from a magnetic drive and showing the movie in movieplayer that causes the problem.[/quote]
How many SSD have you tried? With your example above, I could think the SSD is formatted otherwise than the other(s). Are drive for 1 and 3 two different disks?
Hard disks formatted differently would produce different results; each file system has its own implementation and this makes behaviour differences.
Would it be possible to you to post a screen shot of the disk information (from disk utility) for the drives you tried?

Perhaps not worth dealing with that case, then?

20

For reference a few error codes for Mac OS from MacErrors.h in Xcode:

[code]enum {
abortErr = -27, /IO call aborted by KillIO/
iIOAbortErr = -27, /IO abort error (Printing Manager)/
notOpenErr = -28, /Couldn’t rd/wr/ctl/sts cause driver not opened/
unitTblFullErr = -29, /unit table has no more entries/
dceExtErr = -30, /dce extension error/
slotNumErr = -360, /invalid slot # error/
gcrOnMFMErr = -400, /gcr format on high density media error/
dirFulErr = -33, /Directory full/
dskFulErr = -34, /disk full/
nsvErr = -35, /no such volume/
ioErr = -36, /I/O error (bummers)/
bdNamErr = -37, /* bad file name passed to routine; there may be no bad names in the final system!*/
fnOpnErr = -38, /File not open/
eofErr = -39, /End of file/
posErr = -40, /tried to position to before start of file (r/w)/
mFulErr = -41, /memory full (open) or file won’t fit (load)/
tmfoErr = -42, /too many files open/
fnfErr = -43, /File not found/
wPrErr = -44, /diskette is write protected./
fLckdErr = -45 /file is locked/
};

enum {
vLckdErr = -46, /volume is locked/
fBsyErr = -47, /File is busy (delete)/
dupFNErr = -48, /duplicate filename (rename)/
opWrErr = -49, /file already open with with write permission/
rfNumErr = -51, /refnum error/
gfpErr = -52, /get file position error/
volOffLinErr = -53, /volume not on line error (was Ejected)/
permErr = -54, /permissions error (on file open)/
volOnLinErr = -55, /drive volume already on-line at MountVol/
nsDrvErr = -56, /no such drive (tried to mount a bad drive num)/
noMacDskErr = -57, /not a mac diskette (sig bytes are wrong)/
extFSErr = -58, /volume in question belongs to an external fs/
fsRnErr = -59, /file system internal error:during rename the old entry was deleted but could not be restored./
badMDBErr = -60, /bad master directory block/
wrPermErr = -61, /write permissions error/
dirNFErr = -120, /Directory not found/
tmwdoErr = -121, /No free WDCB available/
badMovErr = -122, /Move into offspring error/
wrgVolTypErr = -123, /Wrong volume type error [operation not supported for MFS]/
volGoneErr = -124 /Server volume has been disconnected./
};[/code]