yes, now it works... i don't know where the ~3 hours of delay come from.
i improved partly the cron job (for uploading / indexing new files) so it is run soon when new files are uploaded or at the given schedule (currently every two hours) so we hopefully have only a delay of a few minutes.
http://jj.darkstars.co.uk was managed by JJ. He did not comply with requests and thus I had to do it myself, requiring I change the password as I didn't have the original email containing it. JJ never asked for the new password despite it being offered. All I have done since is remove htaccess files and change file permissions to make things more open
The details for the account are stored on my main machine ( which recently broke and is being replaced ). It would be a few days minimum before I can regain access to that particular subdomain. I would recommend you amend your system so that host involvement is not necessary ( if only because I can now launch a makeshift attack by modifying the files on my servers, and you would require the cooperation of the attacker to fix it )
i think deleting by hand makes no sense, a blacklist is bad, too.
as springlobby + zero-k (i hope so it does) checks for valid files for now, that shouldn't be a problem.
i made a small update/fix on the searchapi:
the comparison of springname is now binary + underscore is now threated as underscore and not as wildcard. I found that because when searching for "Lost_v2" two results where returned. "Lost-v2", exists, too.
its still a work in progress, but should work nicely.
- result returns links to splash / map images - added metadata in results - sdp hash for all files is calculated - its much more faster than the old one! - search for tags works (ba:latest for example), currently only for files that are also known on springfiles.com - stuff i forgot... - all source can be found at http://github.com/springfiles/upq (moved many stuff from the drupal module into upq)
also: duplicate filenames and version-numbers aren't possible any more on the springfiles.com mirror-system. currently only files on api.springfiles.com are normalized, soon i'll normalize all filenames on the mirrors, too.
broken files (files that cant't be loaded by unitsync) are moved to http://api.springfiles.com/broken/ , maybe this way we get a higher quality of files that are downloadable...
note: i hopefully have soon the courage to activate auto-creating of pages for files on springfiles.com. the code is ready and partly tested, but i fear a bit, that it does stupid things
Users browsing this forum: No registered users and 0 guests
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot post attachments in this forum