Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Mr ChriZ]

If rename files from properties is used to move files to a drive
with insufficient space, then MC attempts to perform the operation
until it can no longer move files.  It then presents a message
box saying it failed with each file that didn't make it.

The files that I requested to be moved were video files.
The files that didn't make it lost all the tag information.

[Mr ChriZ]

yeh ok that goes high up on the list of dumb things to do!

[glynor]

yeh ok that goes high up on the list of dumb things to do!

Yeah.... That's not good though.  I can see that happening to me too.

[park]

I've lost files that failed to move through this operation before too.

[lalittle]

While I haven't run into this, I do think it's an important issue to address.  I just don't always think to check for remaining space when I'm dealing with giant drives since I can go for months without a problem before suddenely hitting this point.  I could easily see myself making this mistake at some point, and given the fact that MC is dealing with HUGE amounts of data, it should be able to elegantly handle this sort of situation.

Thanks,

Larry

[Alex B]

So are you guys suggesting the following:

- MC should check if the used directory string makes the files to move to a different partition.

- If the files are going to be moved then MC should calculate the size of the selected files and compare with the available space.

Since the file system does not always provide accurate info (for example, the file path can be a virtual path that points to the same physical partition or a network path may not provide correct info of the available space) the next step should be

- a confirmation dialog window like this:

The new directory path(s) may not have enough space for the files. Do you still want continue?

This could be a nice feature, but I think MC12 has other more important issues that should be resolved first.

Personally, I have never had a problem with this. I always check the available space first.

[glynor]

This could be a nice feature, but I think MC12 has other more important issues that should be resolved first.

It'd be fine with me if it just recovered more gracefully when it DID run out of space.  In other words, not "lose" the files.  This would mean that it would need to move the files first, and then update the database after confirming that they'd all moved properly (rather than the way it does it now which is update database first, then move files if it needs to make them match).  Or maybe it still updates the database first, but then when it gets the "out of space" error reports "Bonehead, you ran out of space.  Should I reverse the last operation?"

I think this could go along with the request over here...  (Ahh, yes... Gamer's old thread makes a comeback.  I, too, would still like to see some action on this.)

[jgreen]

Are the files actually "lost", as in deleted?  Or does MC simply lose track of them, which has been my experience.  I think "rename . . ." is a very powerful tool that could use some improvement, but like Alex says . . . . 

Park, if thgis happens again, try looking in the files' original location.  I'm betting that you'll find them there, and can reattach them within MC, although it's a hassle.  I think that's what ChriZ is saying (welcome back, where are the pix)--the file is still there but MC had repointed the tag info.

Gamer's request, and Alex B's idea regarding it, are an importan feature for the humongous libraries that Mc handles so well.  IMO, MC needs a way to account for "backup" tracks, links to files which would only be played/restored if the original is offline or deleted.  Each track would have its "twin" viewable only through the "backups" smartlist.

[glynor]

Or does MC simply lose track of them

It does, but if you were renaming 1,000 files and 742 of them got lost (and Otto is turned on) then you've got a serious problem.  Re-importing them can sometimes lose a huge amount of data (if they're files that don't support in-file tags like AVIs for example).

Just figuring out which 742 were lost is difficult even sometimes, and clicking through 742 error messages is CERTAINLY no fun (and often causes things to crash, preventing the Undo action).

(Does UNDO even work for Rename Files From Properties?)

[glynor]

It'd be fine with me if it just recovered more gracefully when it DID run out of space.  In other words, not "lose" the files ... Or maybe it still updates the database first, but then when it gets the "out of space" error reports "Bonehead, you ran out of space.  Should I reverse the last operation?"

I think this would be a simple and elegant solution.   

[lalittle]

It'd be fine with me if it just recovered more gracefully when it DID run out of space.  In other words, not "lose" the files. 

This is what I was thinking of as well.

Larry

[Mr ChriZ]

I think that's what ChriZ is saying (welcome back, where are the pix)--the file is still there but MC had repointed the tag info.

Pictures will be a while.  Most of them are on Film (Yeh remember that stuff?) anyhow they're
currently being processed and scanned in very high res hopefully....

Heres one to keep you going:
http://yabb.jriver.com/cpg/displayimage.php?album=lastup&cat=10045&pos=0

And yeh you're correct basically MC totally lost all information on files that didn't make it.
So I then got stuck between keeping the information on the files that had make it,
and restoring the backup to get information on the files that haven't made it....
If it had managed to keep track of all files, then it wouldn't have been such a problem...