FlashFXP Forums - View Single Post

Stardog · 03-03-2003, 01:27 PM

ok, back from the weekend..lots to catch up on.

First, I agree 100% seting a dir as read only is not a good idea. Also, right now even if I set the sfv to read only it would do no good, there is a bug in the latest io that hoses up file permissions. I have another alternative though

Second I just want to explain the crashes people are having when deleting files. I mentioned on IRC on Friday when I released .94 that it would break postdel compatiblity with races done with previous versions of ioZS. I probably should have made that more clear in my post on this forum. This is because I had to add a flag to the .ioFTPD.race file to keep track if the race was completed yet (this was needed to fix the zips announcing COMPLETE multiple times on those releases with Disk xx/01 when there really was more than 1 disk).

Giant: Have have upped a bunch of MP3s and not yet seen that problem with VA. It determines if the Artist is VA by the release folder name, if it starts with "VA-" then it gets filed under the linkdir\VA\releasename. I plan to write a program that will clean up the broken/missing linked folders. I would rather do that cleanup in a separate program rather than addding it into ioZS, as releases are not always deleted from ioFTPD (some people remove the dirs locally, so I'd still have to have a way outside of ioZS to clean those up). There is one thing I noticed wrong with linked dirs, it doesn't link multi-CD releases correctly, it just links the last CD of a multi-disk set. I'll fix this soon, and should have a cleanup prog. available shortly after I finish with the rescan function.

which brings me to...

zpr: site rescanall is not a function of ioZS, so it will not update the tags correctly. ioZS will have its own rescan function shortly that should correctly update the tags and reace info. .94 has it somewhat built in now. If you remove the .sfv file and resend it, it will recheck all files in the dir.

cdrips: see above, this adds the ability to do what you wanted with adding files locally and having it scan them all.

iSno: I think the only way that could happen is if someone added to a file that already existed. I've kinda seen something like this happen, but is very rare. I wish ioFTPD supported XDUPE or something to keep races from overwriting files already there (or already started).

03-03-2003, 01:27 PM
Stardog Senior Member Join Date: Oct 2001 Posts: 236	ok, back from the weekend..lots to catch up on. First, I agree 100% seting a dir as read only is not a good idea. Also, right now even if I set the sfv to read only it would do no good, there is a bug in the latest io that hoses up file permissions. I have another alternative though Second I just want to explain the crashes people are having when deleting files. I mentioned on IRC on Friday when I released .94 that it would break postdel compatiblity with races done with previous versions of ioZS. I probably should have made that more clear in my post on this forum. This is because I had to add a flag to the .ioFTPD.race file to keep track if the race was completed yet (this was needed to fix the zips announcing COMPLETE multiple times on those releases with Disk xx/01 when there really was more than 1 disk). Giant: Have have upped a bunch of MP3s and not yet seen that problem with VA. It determines if the Artist is VA by the release folder name, if it starts with "VA-" then it gets filed under the linkdir\VA\releasename. I plan to write a program that will clean up the broken/missing linked folders. I would rather do that cleanup in a separate program rather than addding it into ioZS, as releases are not always deleted from ioFTPD (some people remove the dirs locally, so I'd still have to have a way outside of ioZS to clean those up). There is one thing I noticed wrong with linked dirs, it doesn't link multi-CD releases correctly, it just links the last CD of a multi-disk set. I'll fix this soon, and should have a cleanup prog. available shortly after I finish with the rescan function. which brings me to... zpr: site rescanall is not a function of ioZS, so it will not update the tags correctly. ioZS will have its own rescan function shortly that should correctly update the tags and reace info. .94 has it somewhat built in now. If you remove the .sfv file and resend it, it will recheck all files in the dir. cdrips: see above, this adds the ability to do what you wanted with adding files locally and having it scan them all. iSno: I think the only way that could happen is if someone added to a file that already existed. I've kinda seen something like this happen, but is very rare. I wish ioFTPD supported XDUPE or something to keep races from overwriting files already there (or already started).