Is it possible to recover a file that disapeared after renaming?

[Trambopoline!!!]

I was hoping someone could pleasse help me with a slightly odd issue I've encountered.

I should start by saying that I'm running stock firmware.

A few nights ago, I renamed a video file via the Opt+ menu. Specifically, I added "error @0:13" to the end of the broadcast name (see note). My Foxsat didn't show any warnings or anything that would indicate that there was a problem with the new name but when I went to view the file a few days later, it was gone. So I searched the root folder where non-series recordings are stored but the file wasn't there either. So my theory was that the using either an "@" or ":" in the filename is the cause of the problem. My next step was to pop the HDD out of the Foxsat an into my PC but I still can't find the file. There is a folder on the root of the drive, with the new name. The folder in question starts with a period, as hidden folders do on Linux but it doesn't contain any files large enough to be the missing video.


Is there anywhere else I should look for the file, or anything else I can try in order to recover the missing video (up to and including data recovery software)?

NOTE: The "error" mentioned in the file name is just some signal breakup from the broadcast, that occurs at "0:13". As far as I know, there was nothing wrong with the file itself.

 

[Black Hole]

An interesting problem.

I tried an experiment on HD-FOX to confirm what I expected in HDR-FOXland and had a surprise: I did not expect the file name to change, just the metadata which gets displayed on-screen. Adding " error @0:13" to a recording title did not get added to the associated file name, whereas changing an entire title did affect the file name. Illegal characters get substituted with underscores. I don't know anything about the actual mechanisms in the (older) Foxsat UI.

You might have hit a bug; it would be interesting to see whether anyone can reproduce your observation. Alternatively, you might have got unlucky and some kind of misoperation is to blame (perhaps disk fault or file system error).

I presume you are using Linux to examine the HDD. That being the case, you are better placed than anyone else to try to find the missing data, using Linux tools. I don't know anything about data recovery in Ext3, but I presume there are tools available (if it is possible at all – deletion recovery in FAT relies on "deletion" just overwriting the first character of the file name in the directory table!).

Failing that, all I can suggest is the usual e2fsck operations to look for inconsistencies in the file system.

 

[Dino]

Can't reproduce.

Set a 15 minute regional news broadcast to record using the remote - just as single not a series..
This completed as expected saving a file set in 'Video'

Renamed the file using
Media
Opt+
select the file
File Manager
BLUE
Rename
added the text "error @0:13" (without the quote marks) as a suffix
YELLOW

Let me know if you did something different.
If using the remote, I normally use the rename option from the play menu.

Recording shown in the media list as expected with the revised name.
Recording was playable.
Rebooted
Recording appeared in the media list as expected with the revised name.
Recording was playable.
I'll leave it and re-check once the housekeeping generates the thumbnails - but this might be a few days as I've got some overnight recordings coming up.

The above suggests there's nothing inherently 'wrong' with using the @ or : characters.
If there was, it would be odd for the manufacturer to have gone to the effort of including them as optional characters when re-naming using the remote.

The odd thing from your description is the dot directory in the root of the drive.
That sounds like a thumbnails folder but I wouldn't expect to see those in any directory above Video
The fact that it is there suggests something went wrong with the rename you attempted.
Does the dot directory have a suffix in the form "_yyyymmdd_hhmm" where the date and time match the recording start time ?

 

[Dino]

To follow up, housekeeping ran overnight.
The thumbnails for the file set with the "error @0:13" suffix were created as expected.
The file set remained in place and the recording was playable.