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
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

2162
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.

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

2164
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.

2165
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.

2166
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

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

2168
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).

2169
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.

2170
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.

2171
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?

2172
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.

2173
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

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

2175
clrmame Discussion / Re: chd issues
« on: 23 January 2013, 17:11 »
1) your assumption is wrong. baddumps in mame list the hashes of the bad dumps, i.e. you need the files which match these sha1/crc32 values while the status of the dump is still "bad". clrmame only marks files as unneeded which do not match any known sha1/crc32.
For chds, I guess you made the mistake to convert all chds to version 5...which isn't a good idea because the known baddumps will change their sha1/md5 when converting....and that's why they are not baddumps anymore but unneeded....
you should keep known bad_dump chds as version 4 chds.

2) a set is a combination of roms and/or samples and/or chds...so splitting chds from their belonging roms is not really a way to go...but that's still possible to setup in cmpro. However, system-default-paths' purpose is to split sets by bioses/devices/mechanical into one assigned path. So this is totally intended.

2176
commandline will be always limited by its length. so it may work for a couple of files but not for lets say 30 or more...unless there is an option for listfiles where a new file holds the filenames. I will check this

2177
ok...first little improvement(?)...
remove operation for external packers (rar/7z) test if the file in question really exists in the archive....

http://mamedev.emulab.it/clrmamepro/binaries/cmp20130121.rar

let me know if it really speedup things for you....

2178
should be easy to add a test if the file is actually in the archive (however it needs to read the table of contents of the archive again)...and I guess I can
a) filter out real existing files
b) (since the "remove" operation can handle multiple files at ones) maybe use @filelists options...

I will play around with it....

2179
clrmame Discussion / Re: 7z rebuild with @ in filename
« on: 21 January 2013, 20:57 »
ok I've checked the code and I can't repeat an issue with @ at filename start...so an added .\ is obsolete in my opinion... all operations (add, delete, rename) check (in case of 7z/7Z extension) if filenames start with an @....and in that case it automatically adds .\

So Zandro, can you send me a scenario (cmpro.ini, *.dat, *.cmp and the rom files in question) where I can repeat your issue?

2180
clrmame Discussion / Re: 7z rebuild with @ in filename
« on: 21 January 2013, 19:44 »
hmm...actually it should already handle @ at the beginning automatically....I've added an internal .\ fix for filenames starting with @ a long time ago...wonder why it did not work for the mentioned files...need to double check this.
And yes, currently it tries to remove the 'new_name' files first in case of a rename operation.....guess I can change this easily to do this only if the new_name does exist.

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

Page created in 0.239 seconds with 20 queries.

anything