Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Very serious data loss bug in Leopard!
- Thread starter rpp3po
- Start date
- Sort by reaction score
Wow....surprised that basic file operations stuff is having a problem in a 5th generation of any OS.
-Kevin
-Kevin
It might be that exceptions aren't passed correctly from Leopard's SMB code to the Finder's exception handling mechanism. It might also be that the AFP implementation is reporting everything correctly in contrast.
I'm using leopard and haven had a single problem, no missing files or anything
Connor
Ibook G4
Powerbook G4
Macbook pro
Ipod mini
Ipod touch
Connor
Ibook G4Powerbook G4Macbook proIpod miniIpod touchI'm using leopard and haven had a single problem, no missing files or anything
Connor
LOL! I think the thread can be closed now. All following posts are likely to be repetitive patterns of the first 7 posts. Every party has spoken.
This is scary stuff I hope the 10.5.1 update addresses this issue. I think for the most part people will be ok, but if you loss power or finder relaunches people could start getting into trouble. Better fire up those time machine drives.
They are saying Tiger did the same thing.
I think this is BS. Just someone pissed they lost some files because they did a move instead of a copy. I've done the same thing on a windows machine before. Lost files because I broke the samba transfer. I got over it.
Agreed, it shouldn't happen, but sometimes it does. And it bit this guy.
I think this is BS. Just someone pissed they lost some files because they did a move instead of a copy. I've done the same thing on a windows machine before. Lost files because I broke the samba transfer. I got over it.
Agreed, it shouldn't happen, but sometimes it does. And it bit this guy.
At the top of the page it says it applies other Mac OS X revisions as well. You can't blame leopard.
Well I actually got my whole Home folder deleted a couple of days ago. I didn't do any renaming whatsoever, I just restarted and bam, new home folder with the other deleted.
I don't know whether it's related to this though...
I don't know whether it's related to this though...
I glanced over that. Oh well, dunno what to say, sounds pretty bad.
Found this one too, which is actually a whole lot worse as it might affect more people:
Link
If you do a double save in a Core Data app, the file will have 0k.
I always copy files across volumes and manually verify the file count and size matches before deleting the source files. I'm very paranoid with my files.
Moving files across a network is potentially a dangerous thing to do - as far as the sending machine is concerned, the copy has completed when it is told by the receiving machine it has completed. If the receiving machine crashes before the data has been written out from cache (which is what is being simulated), you can get this issue. I'm not sure any OS would handle this any better and I would suspect Tiger will behave in exactly the same manner.
The real fault with this lies with the receiving machine: It shouldn't report success until the data has been written out to hard disk, but in the interests of performance many SMB implementations don't do this. Of course, the perception is the fault lies with the sending machine but IMO this is incorrect. Power or other failures always have the potential to cause data loss when hard disks are cached: It's a price paid for acceptable performance and for this reason I never move files but copy / verify / delete (later)
The real fault with this lies with the receiving machine: It shouldn't report success until the data has been written out to hard disk, but in the interests of performance many SMB implementations don't do this. Of course, the perception is the fault lies with the sending machine but IMO this is incorrect. Power or other failures always have the potential to cause data loss when hard disks are cached: It's a price paid for acceptable performance and for this reason I never move files but copy / verify / delete (later)
10.5.1 doesn't fix move bug?
I did a search, but couldn't verify whether or not this has been reported here. Anyways, it seems that 10.5.1 does not fix the move bug.
I did a search, but couldn't verify whether or not this has been reported here. Anyways, it seems that 10.5.1 does not fix the move bug.
Its not really a Mac OS X bug, its more a SMB problem. This has been around for ages! And who moves files....ALWAYS copy them even within your own system! This is a problem that would require the SMB protocol to be changed to fix this...its not something apple can do.
It's hard to know what that blogger did - he says he dragged from one external drive to another, trying to copy data. There's no reason that would cause the source to be deleted. So if it is indeed a bug, it's not the same issue. However, the links he puts at the end of his post are related to the move bug, which by all other accounts is fixed in 10.5.1.
The move bug wasn't just SMB related - it was shown to happen with all kinds of attached storage including USB thumb drives and firewire drives.
The move bug wasn't just SMB related - it was shown to happen with all kinds of attached storage including USB thumb drives and firewire drives.