Multiple files with same filename on FAT

1. use dd to make a complete image of the drive
2. mount it on the loopback device
3. copy CLIP2.MPG to another location
4. delete or rename CLIP2.MPG - the FAT code will rename the first copy
5. now concatenate CLIP2.MPG (which will now refer to the second file above) with your copied version of the first file
6. lather, rinse, repeat

Vicne schreef in berichtnieuws snipped-for-privacy@19g2000hsx.googlegroups.com...

Are you sure that *that* is the cause of the problem ? Can you play/copy files that do *not* have a duplicate (in the same directory) ?

And what did the error-message say. As far as I can tell the first file of the two should definitily be accessible, and due to the way an MPG works you can view them even if they are not complete.

That fully depends on the OS you are mounting that drive on.

Those map-files are there to solve the problem of the file-system not being able to handle files larger than 4 GB. They have nothing to do with "fast forwarding" or "skipping", but are the equivalent to a FAT (with 4GB clusters) : it will probably hold either pointers to the filename-entries, or pointers to the first block/sector of the 4GB "clusters".

Remark : as the PVR uses that method to store largefiles your computer will need to use the same method when wanting to store edited MPG's back onto that drive again.

Are you sure that the PVR does not have a working network-conmnection, so you can leave the re-assembling (when reading) and dis-assembling (when writing) those files to its embedded OS ?

Regards, Rudy Wieser

Please provide the brand and model of your PVR; there are a great many resources on the 'Net for hacking certain units. If you are lucky to have certain versions of 'replaytv', you have a great many options.

Regards,

Michael

In fact, concatenating may even be unnecessary as I can join the parts in the video editing program. I'd be happy if I could just *read* them separately. So that's definitely an interesting path. Indeed, working on an

Thanks a lot for the suggestion !

Vicne

Yes, definitely.

As I said, I could play other video files in VLC without any problem. I didn't watch a clip from start to end, but I can open them, see the video, hear the audio (in sync), and I can skip forward and backward OK. I tried with three or four without any problem, and the only ones that cannot be read are the "multiple" ones... I admit I was surprised that it was so simple (almost compliant with FAT, no proprietary video format, no encryption...)

You're right, I should have noted the exact message (I'll do it next time), but it's a standard uninformative XP message like 'Error reading file' with only an OK button. The explorer doesn't crash, it simply reports the error. I also tried accessing the file under Command Prompt, but I'm also getting an error.

I was surprised too that none of the two files was playable. I expected that one would be and the other not, or that double-clicking any of them would play the same video, but no : only an error message.

That was XP, but I'll use whatever OS allows me to copy the files over, booting it from a USB stick for example.

That's very interesting ! Do you have a link to more information about the structure of these 'MAP' files ? I quickly googled 'map files 4 Gb' but nothing seems relevant at first. Might look further into that.

Fortunately, I don't want to put anything back to the hard disk. I'll edit and burn DVDs and it will be all.

To give you more info, I'm in the process of converting a whole bunch of VHS tapes to DVD, and VHS to PVR via S-VIDEO gives the best quality so far. Unfortunately, this PVR has no editing feature, and moreover its DVD burner is complete crap : it only accepts certain DVD brands, it only allows about 15 DVD-RW write/wipe cycles after which it considers it's corrupt, and it only works when PVR is cold (burning 2 DVDs in a row fails inevitably).

Yes, I'm sure unfortunately (or maybe the chipset does but it has no external network connection). It's all Cirrus Logic based (CS98301 which I guess is similar to the 98300 they talk about on

Many thanks for the insightful help. It's much appreciated.

Vicne

Well, it's a cheap model branded "Oasis-Media", model DVD-9407. I bought it in Belgium but it seems it was mainly sold in the Netherlands. A firmware update can even be found on

I'm afraid it's not. All I can say is that it's Cirrus Logic based, but even the exact chip reference (CS98301) is not easy to find online...

Thanks for the help anyway.

Vicne

on

After further investigation, it seems it was made by Sampo -

Unfortunately, all references I now find on the net point to the defunct area450.com website, part of which can still be read via the wayback machine on

My version has a 160 Gb hdd but looks exactly the same as the DV-RH680

- see

- but there isn't much information about it online

Reports say it's equivalent to the Sampo DVE-R8HP :

But well, I don't think it's getting me very far...

Vicne

That was what I was not all-that sure about : that the drive-geometry and file-system was recognised by that other computer.

You could try to rename the double file. If you're lucky you won't get an error-message, and only one of the two gets renamed. After that you should be able to copy them to your XP-computers harddrive, where you could than use an utility to stich the files back together again. If you're *very* lucky a simple "copy file1.mpg /b file2.mpg /b resultfile.mpg" would work.

being

"fast

filename-entries,

I'm sorry, no. Its just some info I picked up somewhere when I was searching for answers related to a problem of my own, allso related to an embeded OS and a hard-disk (a LAN-drive actually).

You're welcome.

on

What's the format of the map file? Have you tried running DOS, and simply reading the sector that equates to the first entry in the FAT at the offset given in the map file? If this is the start of the file, it should have a valid MPG4 header at the start. A quick way of finding out what's where would be to run a defrag program on the disc. This will show you which parts of the disc are in use. (Obviously stop before you actually start moving stuff) and you can then figure how these sections of the disc relate to the numbers in the map file.

Matt

It should be safer to first rename all instances of CLIP2.MPG. With all this caching etc in today's operating systems, I wouldn't blindly assume that the "copy" command accesses the same instance than the following "delete" (at least, my ISO9660 implementation wouldn't guarantee that in case of an error like this, and I would use the same caching trick again when implementing FAT).

Stefan

Yes, I also prefer renaming instead of deleting. I'll try that to see if renaming is allowed or if it also gives an error.

Thanks for the help.

Vicne

Yes, I should have tried earlier, but I did all I could not to modify anything on the clone, to allow further investigation... And as you say, I could get an error-message. I'll have to try.

resultfile.mpg" would work.

Yeah, that's not even needed as any editing software will be able to join the pieces.

OK, I see.

Thanks for the help.

Vicne

You REALLY need to think that through, Stefan. If cache coherency is so screwed up, then there is no way the operating system could possibly work. Reads from a drive where write-behind cache is active will read from the cache, not the media.

It doesn't really matter anyway - the important point is, all the FAT code I've ever read, written or tested will only search directories until it hits the first instance of the filespec. So "mv CLIP2.MPG CLIP2.MP0" will only change the first one.

This is where you lost me.

FAT16 uses a directory table and one or more FATs. The entries in the directory table point to offsets into the FATs. To the best of my knowledge, there is no filename info in the FATs.

That makes sense indeed, and I think in any case renaming one of the files is the safest way to proceed.

I was wondering also : I think a solution would be to mimic what a file recovery utility would do. Their job is to decode a source filesystem, detect deleted entries and recover the files they pointed to to another drive. What I want to do is very similar, except I'm interested in duplicate entries instead of deleted ones.

I found PhotoRec -

Do you know of a "file recovery" (or maybe "undelete") utility for DOS with available source code ?

Thanks very much.

Vicne

He didn't ask to read the filename, but the file. All you need is the first FAT entry, and a knowledge of the FAT structure, and you can follow the FAT chain to get all block numbers for the file. The blocks aren't guaranteed to be contiguous. The only missing information is how much of the last block is used.

But really, the best solution here is to open the raw drive in a disk editor, search for the filename, and change each name to something unique. Not hard, and though I haven't done it for years, such programs are out there.

Clifford Heath.

Deleted entries in a FAT filesystem are marked as deleted by changing the first character of the filename to a special magic byte. All DOS undelete utilities look for this signature. Other utilities (which look for deleted files in unused space after the directories are destroyed) work by looking for specific data signatures such as JPEG headers.

If you want sourcecode for a FAT16/32 reader that can do what you want (with some small glue you will have to provide), I wrote one:

You're right.

I'm afraid my sentence was wrong. I didn't mean "FAT entry" but "Directory entry". I mean : If I could somehow navigate the disk with a file manager that showed raw directory entries instead of filenames, I could probably disambiguate which file I want to work with.

Sorry for the confusion.

Vicne

Yes, probably I should begin with that. I started searching with HxD, and let it run for a few minutes, but the estimated remaining time said more than 2 hours, so I cancelled.

It would be much faster of course to read the root directory structure and go straight to the offset of the "VIDEO" folder (the one that contains the files), then perform the disk editing.

The holy grail, though, is a way to get the files out without writing anything to the disk, to be sure it's still recognized by the PVR as if it never was extracted. But I could well undo the editing before returning the drive to the PVR...

Now to automate this, all I need is sample C code to read/write raw sectors on a hard disk (bypassing the filesystem). Anybody has some pointer ?