EMULAB Forum

Please login or register.

Login with username, password and session length
Advanced search  

News:

The new forum is online, hope you enjoy it!

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Roman

Pages: 1 ... 104 105 106 107 108 [109] 110 111 112 113 114 ... 165
2161
clrmame Discussion / Re: Detector rule: size
« on: 29 January 2013, 08:12 »
you used the upper mentioned build already?

2163
clrmame Discussion / Re: Detector rule: size
« on: 28 January 2013, 21:50 »
yeah yeah...I will look at it next week.... :)

2164
clrmame Discussion / Re: Detector rule: size
« on: 28 January 2013, 21:36 »
I will do further checks (scanner/rebuilder) later...maybe next weekend earliest due to some business stuff to do first.....but at least the EOF loop is fixed :)

2165
hurray...

2166
clrmame Discussion / Re: Detector rule: size
« on: 28 January 2013, 20:48 »
well...ok..the infinite loop was caused by a file where the EOF was reached already but not detected....
http://mamedev.emulab.it/clrmamepro/binaries/cmp20130138_header.rar

this should be resolved in that build...however I did not have time yet to think about your original task :)

2167
From the windows api doc:

RemoveDirectory removes a directory junction, even if the contents of the target are not empty; the function removes directory junctions regardless of the state of the target object.

Guess I have to explicity test if the folder is empty before using RemoveDirectory then...

you might want to test this:
http://mamedev.emulab.it/clrmamepro/binaries/cmp20130128.rar

2168
well, as I said....cmpro does pretty basic file / folder operations by calling Windows API functions. A file removal or a folder removal. It does not know about existing junctions. If a folder is removed from the source which is in fact a junction, the OS should actually complain when calling the removedirectory function. I can check if that function got special instructions to let it fail for junctions (so they are not removed) when I find some little time....pretty busy with real life/job at the moment.

2169
well, I guess I can add a check for these empty chd folders to the "wrong merged" test...

2170
well...ok....guess the set had some changes in the past where parent/clone relationsships could have changed....the chd in question belongs to the parent "fghtmn" now...so cmpro moved it most likely to its new correct place. There is no strict rule to mark this folder as obsolete...so it stays (and as described before, it's accepted as a container for the chd...which is identical to the parent and should be stored there in case of full/split merge).......I will take a note...maybe I change the behaviour in the future.

2171
Cmpro simply calls Windows api functions to remove single files / folders... If there are junctions affected, the OS should handle it correctly. I currently don't see why cmpro needs to care about it.

2172
actually, I got the empty folder too...guess pnchmn is some other weird case (could be a fake-clone...i.e. fully identical set)...I will check this as soon as I find some time

2173
clrmame Discussion / Re: Detector rule: size
« on: 27 January 2013, 12:55 »
I will have a look as soon as I find some time....

2174
Junctions???? What do you mean exactly?
The rebuilder reads files (or files within an archive) from a given source, checks the hash values against the database and creates any found match of it in the destination and uses the correct naming. If you got "remove rebuilt files" enabled, it deletes the file from the source (archive) and if the archive or folder is empty after this it gets removed, too (however there is a rebuilder advanced option which allows you to remove empty folders or not).

2175
No it's not ok. You mix up things.

1st of all, there is no "chd folder"....you can theoretically have a rompath with only chds in it...fine...but that's still a rom folder.
2nd of all, you can store sets archived (.7z/.zip/.rar) or decompressed. In the latter case you need to store them in a rompath subfolder named after the set, so "pacman" is a fully valid rompath subfolder name since "pacman" is a set in MAME. If you got both, pacman.zip (.rar/.7z) and a subfolder "pacman", cmpro will tell you that one is obsolete unless the set also uses chds (which are also stored in a rompath subfolder named after the set). This is not the case for "pacman". So if you only got a "pacman" subfolder, cmpro won't warn you because it's a valid set placement. If it's empty, cmpro will warn you about the missing pacman roms of course. If you got both, archive and folder, cmpro warns you as mentioned before.

Back to your first example... said "pnchmn" is not marked as unneeded...and again, correct.
"pnchmn" uses chds, and so this folder is a valid placement for the chd. Of course cmpro will still warn you about the missing chd itself.

...and finally there are chd-only sets which consists only of a chd....so an empty folder for this set is still marked as "unneeded"....there is no reason for it...it is and stays a container for a valid setname/chd placement.

2176
Why should it? Correctly named folders (named after the set) are either used as storage place for decompressed sets or containers for the chd files of that set....If you got the chd check option enabled, you will get an error message about the missing chd.

2177
clrmame Discussion / Re: Detector rule: size
« on: 26 January 2013, 18:50 »
send me the header xml plus dat plus example files so I can have a look at that infinite loop...

regarding your original header idea...what exactly do you want to achieve?

2178
clrmame Discussion / Re: chd issues
« on: 24 January 2013, 08:21 »
1) they are already marked as baddump in the database and if you got the baddumps available you don't see any message (which is intended) because the files do match the hashvalues provided by the database.
By converting the bad ones to chd version 5 you 'kill' them totally (and since the hashes are not matching anything anymore in the database, the files become unneeded)....which is a known fact since the new format encodes more meta information into the final hash value.
Do not convert bad_dump chds to v5. They need to get redumped.

2179
clrmame Discussion / Re: 7z rebuild with @ in filename
« on: 23 January 2013, 19:30 »
thanks...I found the reason :) Actually cmpro does test if the filename starts with an @ and automatically adds a .\ in front of it....however in your case, the filenames got spaces and cmpro automatically adds quotes around them...and then the @ test fails :)
Will be fixed in the next version, thanks for sending such a good scenario....till then you can safely use the .\%2 workaround

2180
with chds, 148 is roughly 300GB and fits perfectly fine on current multi-terabyte hds which cost nearly nothing....

Pages: 1 ... 104 105 106 107 108 [109] 110 111 112 113 114 ... 165

Page created in 0.25 seconds with 17 queries.

anything
anything