Vuze Forums

Full Version: Moving data files leads to recurring empty folders
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Been using Vuze/Azureus for ages now, and I am very comfortable with the settings and configurations within the tool. My problem only started occurring within the last couple releases (maybe 5.2, maybe since 5.0 in fact). First the background/scenario involved.
I have Vuze setup to download to a particular directory (call it DL_Dir).

When the download is completed, I have it move to a staging folder where it continues to seed (call it Ready_Dir). This rule is set in the Options | Files | Completion Moving.

At some point in the future, I move it to a different location (call it Longterm_Dir) by right-clicking the completed Torrent, and selecting Advanced | Files | Move Data Files. Files in this location are always accessible, but Vuze will Start or Queue them based on seeding Auto Starting rules.
Everything works perfectly, and I have no problems with Vuze's performance or ability to handle these scenarios.

The unexpected behaviour I am experiencing is that as time goes on, Vuze will randomly (re-)create the directory structure for a previously completed (and moved) torrent in the Ready_Dir folder, but with no data files. Just directory structure, sometimes just root folder, sometimes deeper, but never quite the complete directory structure of the completed torrent. Not every seeding torrent in Longterm_Dir gets re-created, just a handful. This makes it annoying when I have to manually delete these folders, since I use my particular 3-folder sorting for various reasons. 

Is this a bug? Is this the result of some configuration that I inadvertantly set?

Java 1.7.0_71 Oracle Corporation SWT v4233, win32 Windows 7 v6.1, x86 V5.4.0.0/4 az3
Windows 7 x64 Home Premium 
 

 
That's a weird one, not come across it before. My only guess would be that something is checking to see if the initial automatic 'move on complete' has occurred and in doing so creates some folders. Perhaps it then goes ahead and tries to delete them and fails because of something (AV locking a folder, dunno)

Can you check the log files (the debug_1.log and debug_2.log files) to see if there's anything about 'unable to remove blah'?
Well, looking in debug_2, I see numerous lines similar to the following. Since I regularly purge the shadow folders, I can't match times/dates, but this one matches a recent appearance. (Filename and folder redacted for privacy)

[17:35:32] [stderr] DEBUG::Thu Oct 30 17:35:32 EDT 2014::org.gudy.azureus2.core3.download.impl.DownloadManagerController::filesExist::1807:
[17:35:32] [stderr] Accessing 'C:\filename' in 'folder' took 1277ms - possibly offline
[17:35:32] [stderr] DownloadManagerImpl::filesExist::1552, DownloadManagerImpl::initialize::1685, DownloadImpl::initialize::319, StartStopRulesDefaultPlugin::process::1430, StartStopRulesDefaultPlugin$StartStopDownloadListener$1::run::604, AEThread2$threadWrapper::run::297


Seeing this log entry, it reminds me that I am using a plug-in to control seeding: Autopilot v0.5.1
Did some (preliminary) digging, and the problem does not appear to be AutoPilot, but appears to be in Vuze's "DownloadManagerController.java", or at least where *it* thinks the file should be. I don't have the tools to debug, but hopefully that's a pointer in the right direction for some developer!
I've tried reproducing the issue with a torrent with a few folders+files (download to X, move on complete to Y, manually move to Z - stop/start torrent, force recheck, start/stop Vuze) with no luck :( It sits there in Z and I don't see anything appearing in Y.

Can you think of anything else you do with your downloads that might be triggering it? Streaming/Transcoding...?

The log regarding slow access to a file is often see on network attached storage that needs to spin up - are your X,Y,Z on a local disk?