Print

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

[crisnee]

I'm using MC 21.15. I just lost all my video files, movies etc. while updating the tags. I got the message something like "are you sure you want to update the tags it may take a long time." Next thing I know, basically a second later, all my files were gone. Of course I couldn't undo nor were the files in the trash. How annoying is that.

All these annoying safety questions that can't be turned off every time I do some little thing, but when it really counts MC just irrevocably deletes many giga bytes of updated files in a split second with no notice or safeguard at all. And no I can't give anymore detail.

Chris

[darichman]

This sounds highly irregular. What tags were you updating exactly? How were you updating the tags? Were you using 'Rename, move and Copy Files'?

If you were truly just 'updating tags' MC is not going to delete any files. It just won't. It may move files, but only if you are using the 'Rename, move and Copy Files' or specifically updating the 'Filename' fields.

If you press delete on your keyboard (or select delete from the Edit menu), you will get a prompt "Are you sure you want to delete... etc". The outcomes of the prompt are clearly detailed.

And no I can't give anymore detail.

That's a shame.

[~OHM~]

I would guess user error!

[RoderickGI]

The files aren't gone. You just can't see them in the view you are using.

Look under the appropriate, or every, file view. Or check using Windows Explorer.

[blgentry]

As others have said, unless you were using Rename, Move, and Copy the files probably are just no longer visible in the video view you are using.  As a TOTAL guess, you probably changed either the Media Type, or the Media Sub Type, which would make your files not show in the views you expect.

Try Video > Files and see if they are there.  Try searching, in that view for some names you know should be there.  If you've accidentally done something really wacky like changed the Media Type to Data or something else that's not in a common view, you might need to make a new view that shows EVERYTHING.  I have a view like this in my Tools group, just in case I can't find something, or I want to see everything together.  I can walk you through that if necessary.  It's easy. 

Good luck and let us know what you find.

Brian.

[crisnee]

Hey Guys,

Let me say that I know what I'm doing when it comes to computers, so I'd already done all suggestion before coming here. The files are gone. I didn't bother with looking for them via MC; I went directly to explorer. I also wasn't worried about getting them back, I have backups (the only problem being that my backup drives are elsewhere at the moment). I was doing two things, letting people know that a serious problem exists somewhere and expressing annoyance  .

By the way, I recovered the files that I needed right away via RECUVA, a nice little free file recovery program.

Chris

[blgentry]

Wow that's not good.  The only way I know of deleting files from disk in MC is to use the delete option and then say yes to the two different prompts.

What exactly were you doing when this happened?

Brian.

[glynor]

I was doing two things, letting people know that a serious problem exists somewhere and expressing annoyance  .

Unfortunately, without more information, no one can even guess what you might have done to cause that.

If you edited the [Filename] tag directly, it could cause... Bad things to happen, and would show that prompt.  But, I don't know how you'd have gotten there, and even then, the update wouldn't only take a second or two.  Anything that accesses the disk or moves files will take substantially longer.

More information would be useful, even if it just helps to warn others.

[crisnee]

Wow that's not good.  The only way I know of deleting files from disk in MC is to use the delete option and then say yes to the two different prompts.

What exactly were you doing when this happened?

Brian.

Glad you asked that; I was just about to explain. I was rebuilding the thumb nails. I never used the copy, rename, delete (or whatever it's called) during this session.

Chris

[crisnee]

Unfortunately, without more information, no one can even guess what you might have done to cause that.

If you edited the [Filename] tag directly, it could cause... Bad things to happen, and would show that prompt.  But, I don't know how you'd have gotten there, and even then, the update wouldn't only take a second or two.  Anything that accesses the disk or moves files will take substantially longer.

More information would be useful, even if it just helps to warn others.

Exactly. It just happened so quickly and unexpectedly and I wasn't doing much at all that there's not much help to give. I'd spent 5-10 minutes in this session and the last thing I did was okay one of those "this could take a long time" (tagging) messages. A Split second later the files were gone.

Chris

[crisnee]

By the way, to the powers, I suggest that all files be deleted to the trash bin. That way the message "files too large for trash bin" gives one another chance to undo an erroneous delete or in this case avoid possible disaster.

Chris

[mwillems]

Exactly. It just happened so quickly and unexpectedly and I wasn't doing much at all that there's not much help to give. I'd spent 5-10 minutes in this session and the last thing I did was okay one of those "this could take a long time" (tagging) messages. A Split second later the files were gone.

Chris

I would like to say that I had something very similar happen to me a twice in the last year.  The most recent was a month or so ago.  I was doing some tag editing of a few albums in a view on a Linux client with my windows server open in a VNC on the other monitor.  Suddenly, I saw my server applying changes to all 60 thousand music files.  The "change" in question was deleting the files!  I managed to force quit MC and revert to an older library but by the time I'd stopped it about 3 thousand files had been deleted.  

That was the second accidental library event I'd had in about six months.  The first one happened in very similar circumstances (tag editing on linux client), but it didn't delete files; it "applied changes" to every audio file in my library and I had no idea what had even been changes (it would be nice to have some way to find out what tag changes are being made rather than just the number of files left to do, but that's a separate issue).  

I wrote off the first one, because I was typing fast, I thought I might've miskeyed, or double-pressed or something (i.e. user error).  But the second time I was sitting there quietly tagging a couple albums and there was no "accidental contact"; just sudden database mayhem.  In both cases I restored from backup, so no data lost, but it was definitely scary.  

I didn't pursue it because I had no way to reproduce anything, and I know that Linux MC still has some kinks (and I didn't want to spread FUD), but if other folks are seeing this, maybe it's worth discussion.  I definitely stepped up the frequency of my backups.

[RoderickGI]

Okay, we all stand corrected.

Deleting many gigabytes of data in a split second is most unusual, particularly if the data is on a rotating disk, and if it is many small files, as audio files would be.

It would be nice if there was some way to avoid that happening to other users, like me! I don't have backups of all my non-critical media files. 

[glynor]

I have an idea of what could have happened.

I was writing up my response to this thread and something occurred to me:

I know (from previous tests) if you select a whole swath of files, edit the [Filename] tag and make them all c:\foo.txt (or something similarly dumb), it will not hose you.  It will move the first file to c:\foo.txt and then the system "overwrite files" dialog will come up and warn you of your mistake before too much damage is done.  To obliterate everything, you'd have to click OK umpteen-thousand times over and over like a monkey.

But what about if you just clear the [Filename] tag? Edit it, delete what is there, but put nothing at all in the box.  I've never tried that.  So, I just tested it.

Yup, it obliterates the files. It also gives you a tagging error, and the file entry becomes broken in MC (1/2 way changed).  But, before it does that, it deletes the files and they do not go to Recycle.

That should be fixed. If you are direct editing the [Filename] it should test the user entry and make sure a valid filename is entered before doing anything (or at least not just whitespace)!

I'm not sure that's what happened here. Because it isn't super instant (I watched it delete a few files, but doing the whole Library would have still taken a while), and it should have at least shown an error about tagging when done, so I'm not sure that was the case here.  But, still not great, and could have been what bit mwillems.

Also worth mentioning, I had a similar experience to mwillems too, a good while back. I did post about it, but didn't have many details. I'll look for the post later.

[mwillems]

I have an idea of what could have happened.

I was writing up my response to this thread and something occurred to me:

I know (from previous tests) if you select a whole swath of files, edit the [Filename] tag and make them all c:\foo.txt (or something similarly dumb), it will not hose you.  It will move the first file to c:\foo.txt and then the system "overwrite files" dialog will come up and warn you of your mistake before too much damage is done.  To obliterate everything, you'd have to click OK umpteen-thousand times over and over like a monkey.

But what about if you just clear the [Filename] tag? Edit it, delete what is there, but put nothing at all in the box.  I've never tried that.  So, I just tested it.

Yup, it obliterates the files. It also gives you a tagging error, and the file entry becomes broken in MC (1/2 way changed).  But, before it does that, it deletes the files and they do not go to Recycle.

That should be fixed. If you are direct editing the [Filename] it should test the user entry and make sure a valid filename is entered before doing anything (or at least not just whitespace)!

I'm not sure that's what happened here. Because it isn't super instant (I watched it delete a few files, but doing the whole Library would have still taken a while), and it should have at least shown an error about tagging when done, so I'm not sure that was the case here.  But, still not great, and could have been what bit mwillems.

Also worth mentioning, I had a similar experience to mwillems too, a good while back. I did post about it, but didn't have many details. I'll look for the post later.

That's a plausible model for what happened to me.  It was certainly not instantaneous, but it was moving at a clip of a few dozen files a second, and I was confused for a minute about what was happening so it took me a minute or two to force quit  (and to remember how to get into task manager via VNC).  That's how it got to 3k in my case.  It would have taken a while to iterate over everything, but if I hadn't been watching my server instance I'd have never realized it was happening until much later in the process.

[RoderickGI]

The blank [Filename] field with multiple, or all, files selected sounds like a plausible cause.

Maybe a user shouldn't be allowed to edit the [Filename] tag if more than one file is selected, unless an expression is being used, and that expression is validated in some way to provide unique results.

I have edited the [Filename] field directly a few times, carefully, and was surprised at how powerful doing just that can be, since it renames the actual file.

Perhaps all of the [Filename], [Filename (name)], and [Filename (path)] fields should have an extra warning popup when they are edited directly. Except of course;

All these annoying safety questions that can't be turned off every time I do some little thing, but when it really counts MC just irrevocably deletes many giga bytes of updated files in a split second with no notice or safeguard at all.

[glynor]

I think a more likely cause for the OP's issue is that the files were deleted somehow externally (by something outside of and unrelated to MC) and then when MC opened and tried to use the files, Auto-Import with Fix Broken Links would immediately remove all the files.

That would explain the instantaneous nature of the issue. Auto-Import would eventually have found the files missing, and removed them, but trying to update all of the tags would "cause it to notice" (because otherwise it only responds to changes it sees happen on the filesystem, and scans periodically).  Removing broken liks from the database is lickety-split quick, even for 10s of thousands.

But, perhaps not... If somehow you edited the [Filename] tag with all files selected, and made it blank, and didn't watch (or waited for the changes to finish) you could cause havoc.

[crisnee]

In my case, the only thing I did with this particular batch of files (all my video files scattered across several directories--sidecar files and jpgs in directory concerned were also deleted) was rebuild thumbnails. I'd done something to some of the files but not all earlier, but all were deleted.

Chris

[crisnee]

Well, thank-you. Simultaneous changes I think.

Chris

[glynor]

In another unrelated thread, cncb brought this up:

Another strange thing I found while testing this is that when you edit a field in the Tag Window with no files selected, the change is applied to all files in the list?  This does not seem right to me at all.  In my opinion, if nothing is selected then the Tag Window should be disabled.

I replied...

This is correct.  I think it is to allow you to speedily mass-edit tags. So, for example, to apply a tag to an entire artist worth of files, you can just select the pane in question (then all files are, in effect, selected) and change something in the Tag AW.

But, I agree, it is dangerous, and probably not worth the tradeoff if it is that way on purpose (and it has been that way a long, long time, as long as I can remember).  In fact, it could be related to this:
https://yabb.jriver.com/interact/index.php?topic=101408.0

Back when I deleted everything (or started, but caught it and stopped it before it finished), it may have been related to the everything is selected when nothing is selected functionality of the Tag AW. Like this:

1. Accidentally get focus on the [Filename] field, not understanding where the cursor is...
2. Hit the spacebar trying to start playback...
3. And then (confused when spacebar doesn't work) maybe hit the Enter key...

And whammo, your whole Library, deleted.

I agree, the Tag AW should be read-only until at least one file is actually selected. Not disabled, mind you (because it is useful for informational purposes), just read-only. This would match the behavior of the tagging checkboxes in the panes, and is much, much safer.

[cncb]

I agree, the Tag AW should be read-only until at least one file is actually selected. Not disabled, mind you (because it is useful for informational purposes), just read-only.

I say disabled because I had a situation a while ago where this presented a problem.  I had a complicated calculated expression field in the Tag Window that would parse the Keywords field with several list operations.  When I would open a view with several thousand files, MC would appear locked up for several seconds because presumably it was calculating the expression for every file.

[glynor]

I don't think you can disable it because of that kind of edge case. It is a valuable display. I keep it open often for expressly this purpose (to look for Varies in a field that should have a value, for example).

Read-only makes sense. Disabled breaks things.

[glynor]

Maybe a user shouldn't be allowed to edit the [Filename] tag if more than one file is selected, unless an expression is being used, and that expression is validated in some way to provide unique results.

I don't think you can do this.

First off, I've used direct editing the [Filename] tag more than once to solve problems. In fact, that's exactly how RMCF works. In Rename mode, it is basically just a specialized tool for mass-editing the [Filename] tag.

The expression engine can't really distinguish between plain-text entry and an "expression".  They both output a plain text string.  An "expression" is just some text that happens to contain special function() identifiers that are parsed out and replaced inline with the resulting text. Everything you enter is an "expression". Just some of them don't contain any functions (and so are then passed through verbatim). And, by the time the "tagging" step happens, the expression has already been parsed, and it just gets plain text.

So... Not that, but I agree something should be done to protect [Filename] changes from invalid changes. At the very least, check to see if the entry was only whitespace. That's obviously bad and deletes the files!  Better would be to also do some basic sanity checks to see if it can resolve to a filesystem location. For example, the result must begin with one of:

* <letter>:\
* \\
* / (on POSIX platforms)

I don't know if MC for Mac can resolve smb:// style names, but maybe include those too if so.

[glynor]

Well, I discovered more. It isn't just whitespace, and they aren't actually deleted (it is still a calamity though).

If you edit [Filename] and type any "invalid" filename, it goes kablooie. I just tested this:

1. Select a MP3 file (after making a backup copy).
2. Edit the [Filename] tag, and typed: cheetos.mp3
3. Hit enter.

The file vanished and went to nowhere. But, then I found it.

I ran search on the whole computer for cheetos.mp3 and low and behold, after a long time, it found it. Here:
C:\Users\glynor\AppData\Local\Temp\7zSE4D2.tmp

And, inside that folder? I had the cheetos.mp3 file. And, the album I previously "deleted" (earlier tonight) by clearing the [Filename] tag! Those files were there too! They still had their original filenames, but, of course, they'd lost their folder structure. So if you did it to a big swath of files, you'd be deeply and seriously hosed. But, they aren't gone, just moved to temp.

Of course, then your temp folder can get cleared out. MC doesn't seem to clear those itself (or not right away) as I closed and re-opened MC and they're still sitting there. But, maintenance processes certainly will clean them out eventually.

You might want to check through your AppData temp folder, to see if you have a bunch of "deleted" video files in there sucking up space. That would be a telltale sign too, of this issue.

[crisnee]

I checked my Appdata folder and everywhere else and was not able to come up with any errant video files.

Chris

[crisnee]

And now that I think about it, of course not. I had to recover my deleted files with a file recovery utility, which means that they wouldn't also be available in some temp folder--or anywhere for that matter.

Chris

[glynor]

I agree, the Tag AW should be read-only until at least one file is actually selected. Not disabled, mind you (because it is useful for informational purposes), just read-only. This would match the behavior of the tagging checkboxes in the panes, and is much, much safer.

Bump.

[crisnee]

While trying to recreate the problem recently (I was unable to) I ran into another problem.

I selected a group of video files and rebuilt their thumbnails. Doing that created duplicates of some of the files which were named filename.1. and were placed next to the original. I've since deleted the duplicates, so I don't have more details except that the duplicates were true duplicates.

Chris

[glynor]

Just this weekend, I manually rebuilt thumbnails on about 7000 files in MC (files on my offline disks I use for long-term storage). I had no issues, and certainly no duplicates, so you'll need to be more specific.

[crisnee]

What do you mean by "manually" rebuilt. I just highlighted the files I wanted to rebuild and chose the rebuild option.

Chris

[glynor]

Yep. Like that.

[fitbrit]

While trying to recreate the problem recently (I was unable to) I ran into another problem.

I selected a group of video files and rebuilt their thumbnails. Doing that created duplicates of some of the files which were named filename.1. and were placed next to the original. I've since deleted the duplicates, so I don't have more details except that the duplicates were true duplicates.

Chris

Perhaps the thumbnails are designated read-only? If that's the case, maybe the thumbnails could not be over-written and new ones were created?

[blgentry]

Reading fitbrit's post, I'm realizing I may not understand the problem report.  The duplicates:  Were the video files duplicated?  Or were the thumbnails duplicated?

Brian.

[fitbrit]

Just re-read what I quoted. Likely it was I who misunderstood. Weird if the video files themselves were duplicated.

[crisnee]

The video files themselves (some of them) were duplicated and renamed something like filename with a .1 added, i.e. flowers blooming.1.mp4. I tried duplicating the problem but of course, wasn't able to ?. It had happened several times before, I swear, as I was careful when deleting the duplicates because I didn't want to delete a "seeming" duplicate that wasn't somehow a real duplicate.

Because I wasn't concerned with reporting the problem here initially I didn't check for any clues, i.e. if it only happened to particular types of video files.

Sorry for my slow responses but my regular browser (Chrome) doesn't want to play nice with MC recently. Is anyone else experiencing JRiver forum problems with Chrome?

Chris