I do , however, get those fuggin annoying , reboot your machine messages, on several occasions....for no apparent reason.

Oh and the import function in Iphoto doesn´t work at all in Leopard rendering Iphoto as useful as a chocolate teapot.....

--
bombholio

If I try and move a subfolder from a folder on an internal IDE drive (not sure if that's relevant) to the desktop, then try and move ANOTHER subfolder from the same folder to the desktop, I get the message.

If I try and move a FILE from a subfolder and then a file from a different subfolder in the same parent folder, to the desktop, I don't.

But if I try to move the files back, I get the message for the second one.

Fucking weird, and fucking annoying.

--

a) Leopard isn't released yet, and I suspect your 'reboot your machine' messages are a result of bugs that are still to be ironed out.

b) I'm happily doing multiple copy/moves here in Tiger.

--
simon

/Some volume/Films/ABadFilm/poofilm.avi
/Some volume/Films/AWorseFilm/crapfilm.avi

Start a MOVE of poofilm.avi to your desktop, then start a move of crapfilm.avi to your desktop.

Does it complain? (doesn't on mine).

Once there, try moving them back, independently, to the same directories they came from, and see if you get the message. I do.

That would I think definitively tell me if something weird is going on in my system, and if there is, I bet it's down to some utility or other I've installed... I can't see any other explanation at present.

--

When I drag these files to my Desktop, this triggers two copies, not two moves.

When I drag each of them back to where they started, this is also a pair of copy operations and so the Finder prompts me with:

... and when I click 'Replace', each one completes just fine.

--
simon

I also get Copies by default but (I failed to mention) I'm pressing Apple or whatever the key next to space is called, to change it to a move.

When I do as you have just done, I get exactly the same.

The plot thickens. After copying the two files to the desktop in the same manner as you did, if I then go to MOVE one back, then because the file still exists at source I get the Replace/Stop dialog. If before answering this I initiate another MOVE of the other file back to its source, I immediately get the message that the source file is busy.

If I initiate the MOVE *after* answering the question, I also get the busy message.

Interestingly, if I don't answer the question and meanwhile try and copy ANOTHER file to the desktop, I get a dialog telling me it's preparing to copy, which doesn't actually START to copy until I answer the question in the other dialog (regardless of how I answer it).

All of which leads me to understand that if there's a MOVE going on, the source folder is locked until it's complete, which kind of sucks. I mean, surely a Move is just a Copy with a Delete at the end. Why lock the source folder? In case someone deletes the file in the meantime? Well then why not just lock the file? (even though actually it wouldn't matter if it's deleted; it was going to be deleted anyway).

It's certainly no big deal but this is one area in which I'm forced, begrudgingly, to admit that XP is superior.

--

I just tried to delete those two attachment files from the desktop while moving one of those films back to where it lives... got the '...in use right now' message.

--

1) Copy + delete (when moving a file from one filesystem to another) or

2) Update the relevant metadata when moving a file from one place on a filesystem to another place on the same filesystem

In simple terms, moving a file around on the same filesystem can be an atomic operation whereas moving a file from one filesystem to another is not (because it involves copying + deleting).

I can only think that you're running into an issue where the OS is protecting you from what would happen if, halfway through the copy+delete, someone else on the same system (it's multi-user, remember) tried to do something that might conflict with your actions that are in progress.

XP probably doesn't care if your data gets trashed en route if someone nips in and deletes the file that you are in the middle of moving to another filesystem, so that the next time your process goes to the disk for the next few MB to buffer up, there's nothing there with that filename any more that it can read from.

Pure speculation on my part, of course.
--
simon

--
bombholio

If you try and delete a file which is mid-move from one disc/filesystem to another, XP will think for a few seconds (it tries a few times with a pause between) and then tell you it can't be deleted.

And whilst you could open the file that is being moved (up until it is deleted as the coup de grace of the move, obviously), you could not save any changes you made to it.

XP allows reads but not writes to files being moved (and copied).

Which to my mind makes perfect sense -- more sense than preventing reads as well, although I'll grant I don't know why OSX seems to do that.

I'd like to believe it's for some sound technical reason, as Simon postulates, but personally I feel it's more likely to be because it's not been thought through properly, or not considered important enough to make right. There's stacks of stuff like that in both OSX and Windows.

--

Touche. I know it was bollocks wasn't it, but then I blame that little shop up the road that i visitied not 30 mins before resuming posting. My mishtake. (at least my Dutch accent is coming along nishly :)

--
bombholio

So continuing to assume (2), with XP you might get some weirdness like the file being moved might not get deleted after the copy part of the move if someone started using it during that time, and you might get an error dialog telling you this, or something vaguely approximating it, but it wouldn't corrupt it.

Maybe XP just uses (and I don't see why this shouldn't apply to files systems as well as DBMSs) optimistic locking when it comes to moving files around, and OSX pessimistic.

--

Does it happen if you rule the Desktop itself out of the equation? eg choose a different folder than Desktop for the destination.

--
simon

(Bear in mind that I haven't looked into any of this on my machine yet.)

--
stevepa

I reckon it would still be better for it to lock the file at such time as it actually needs to (at the Delete part of the Move) rather than waaaaaay beforehand (at the start of the Copy part). It just seems overly, well, pessimistic, since Spotlight doesn't need to write to the file.

--

(Amit Singh, who works for Google, wrote a very good book on Mac OSX Internals which may explain some of this although I've not read it.)

--
stevepa

Nice one Bruce.....

--
bombholio

--

--
bombholio