No stats in "copy progress window" when moving

[boli]

the new "copy progress window" is excellent, a very nice feature!
It doesn't do much when moving files though*, all one sees are the files that are moved, but none of the statistics that are shown when copying...

no biggie, probably an oversight?

cheers, oliver

* (in case not everybody knows that: dragging & dropping a file/folder to another volume with the command key pressed will move it instead of copying; likewise, one can force a copy with the option key when dragging & dropping something on the same volume)

[thePervertedMonk]

Edit: editted subject to accurately describe issue. Only the move dialog, both local and network moves.
--
Not sure if this has been reported/ dealt with elsewhere, but I've found it several times.

While copying (huge?) files across the network, the only information that is displayed in the copy dialog is the File/ Folder name.

-no transfer rate
-no time left/ expired, etc, etc.

Copy dialog appears functional for normal local HDs though.

a)
Shared Resource: WindowsXP Workstation.
Sharing services: windows file sharing.

--This has happened several times during tests, while copying from a Windows share.
File sizes upwards of 500MB

b)
Shared Resource: Linksys EFG120, running a unix variant.
Sharing services: samba.

Copied a 100MB file; Copy Dialog showed expected details.
--Will try with a larger file and see if it's a file size issue or a "share resource" type issue.

[boli]

hmm, i've seen the same behavior when moving files

when copying things have worked fine, even copying 500+MB files to a windows machine...

[thePervertedMonk]

Actually,

Correction, yes.

The 400MB+ files were moved.
The 100MB file was copied.

So the situation as stands is: seems as though there's some error in the move dialog when moving from across the network.

[boli]

in my experience it doesn't matter wether you move files on your local disks or to a network share...

[thePervertedMonk]

Boli,

So the dialog is incomplete for you whether the move is local or network share?

(testing it right now...)
--
Edit: Tested: local moves are definitely missing info in the move dialog also.

This should be fixed fortwith, I initially almost cancelled a 1.7GB transfer, as the progress info, was missing, fortunately I had the patience and peace of mind to actually check for several of the moved files.

[boli]

screenshots!

copy:
http://homepage.mac.com/boli/copy.png

move:
http://homepage.mac.com/boli/move.png

btw, i bought the game, just keep a copy on my mac so i won't have to find the cd. :D

[thePervertedMonk]

Boli,

Just adding a bumpty-bump of sorts.

[neilio]

Probably just an OS bug. We just ask the OS for information, and if it doesn't return it we can't display it.

A good example is when moving bundles - the OS can tell us the total number of files in a bundle, but it can't tell us how many of them have been copied. I'll confirm this with Steve when I talk to him, but I'm pretty sure this is what's preventing us from showing any data during moves.

[thePervertedMonk]

Probably just an OS bug. We just ask the OS for information, and if it doesn't return it we can't display it... but I'm pretty sure this is what's preventing us from showing any data during moves.

Neilio, did another test.
Just to confirm, moved a file, from across the network, with PF3.2.2.
PF3.2.2 does show the amount of data copied, and it does increment as expected. [note: nothing else is displayed as the dialog does not request and hence does not display it.]
--

Whereas, the dialog in PF4, ONLY shows the filename, regardless of all the info requested from the process.
--

Maybe PF4 is requesting more info from the OS than PF3.2... but on the same version of the OS, with a different version of PF, the older version (3.2) displays more info than the newer ver (4). [i.e., the older version displays all the info requested/displayed, the newer ver, only displays the name, and not even the basic info that PF3.2 displayed].

So definitely something else is amiss, not a big/HUGE error, but obviously maybe something related to the management of the data/fields being requested by the move process.

Hope this helps.

[boli]

I'd imagine the change from PF3 (Carbon update: wrong, see below) to PF4 (Cocoa) required changing the APIs used to poll the OS, so they might get other kinds of information... it looks like some nice stuff hasn't been implemented in Cocoa (yet?), as for example the stuff to support smart folders etc, so this wouldn't suprise me.

on the plus side, network copies are full speed now (say 50 MB/s rather than 5 MB/s in a gigabit network).

cheers, oliver

[daisy55]

not sure if this is even relevant, but wasn't PF3 cocoa as well?

if so i'd imagine the change just has to do with the fact that the copy/move engine was rewritten, i thought.

as for nice things not in cocoa (smart folders, etc) it baffles me that apple's "flagship" api is so crippled sometimes. i know carbon is a legacy, and therefore has the edge in AS, etc, but even so - we're on 10.4 already, come on guys.

[BrentN]

PF3 was Cocoa. You know though, there really isn't some Boolean switch that makes an app Cocoa vs. Carbon. Many, many applications use both frameworks. What people typically mean by drawing a hard line is whether the UI elements are done using Cocoa or Carbon. But that has no effect on how you handle AppleEvents.

Applescript has really been a 1st class citizen in Cocoa since 10.3. Writing the new scriptSuite and scriptTerminology files make for easy AS implementation for the developers.

The real issue here is what APIs Apple makes public - i.e., smart folders. Apple simply hasn't exposed an interface to that functionality to developers yet. This typically means that the feature isn't considered "stable" enough. (in this case, stable doesn't mean "crash" but rather, the internal implementation of the feature is subject to change). When the Apple engineers get their code locked down, it will be made public.

[boli]

oh, my bad. i just updated my earlier post. thanks for the correction & additional info! =)

[florean]

When I move a files to my external FireWire drives (and I'm pretty sure my USB drives; possibly network drives as well), I get no status information at all, other than the name of the file currently being moved. Even the progress bar doesn't show any information, just the spinning candy-striped bar it normally shows while calculating the size of the files being copied. Whether I move a single file or multiple ones doesn't matter. If I copy the file(s), the status info shows up as expected. This still occurs in 4.0.1.

[sportbiker]

Ditto here on my external FW drives.

[neilio]

There's not much we can do here - we simply ask the OS to give us information on what's happening and then we display it. There are a bunch of issues with the copy engine in OS X which we've filed with Apple, and this is one of them.

Another example - if you copy a bundle (like an application) PF can show the total number of files contained in the bundle, but can't display an update of how many files have transferred - another limitation of the OS.

[Ben Schwan]

Pathfinders moving routine seems to need some work. When I copy stuff, all is displayed correctly (i.e. size, speed etc.). When moving (i.e. command-drag to another drive), I don't get any of this information, only a progress bar which doesn't progress. Also, it's not possible to stop the moving.

Is this a known bug?

[neilio]

I believe this is an OS bug - Steve has passed this on to Apple for investigation.