funchords Posted June 29, 2007 Report Share Posted June 29, 2007 With build 2951, I successfully uploaded a directory across a read-only Windows network share. My next upload was on the same share, but was a single file. UTorrent threw an "access denied" error and I was forced to use a writeable share.1. Click the "Add New" button, navigate to the .torrent, and click OK. The "Add New Torrent" window opens.2. Click the "..." button and navigate to the file on a read-only share. Click Save. An error appearsTitle Bar: Save AsContent: filename.aviCannot access this file.Check security privileges over the network drive.This is moderately important to me. I would like to use read-only shares to keep me from accidentally overwriting my files. So my preferred behavior is for uTorrent to allow me to access the file across the read-only share, and only throw an error if the hashcheck fails and uTorrent wants to write to the target and cannot. I'm sure this problem existed in the previous release, and if I was you, I would not hold up the next release if fixing this bug is complicated. I definitely would appreciate it if it could be fixed, but I can live with it.I can reproduce this on build 2999, too. Link to comment Share on other sites More sharing options...
Ultima Posted June 29, 2007 Report Share Posted June 29, 2007 Mm... The devs have added this to their todo list. Not yet sure whether it'll make it into 1.7. Link to comment Share on other sites More sharing options...
Honeyfrog Posted June 29, 2007 Report Share Posted June 29, 2007 Actually, it'd be a sweet improvement if there were a "lock torrent" command on the right-click pop-menu; it'd prevent uTorrent from downloading while permitting uploading. It'd be a lot easier than manually messing with file properties (a DL rate of zero isn't presently implemented either)....I'm going off to put this in requests right now.... Link to comment Share on other sites More sharing options...
Ultima Posted June 29, 2007 Report Share Posted June 29, 2007 Don't bother. It's already been requested. Link to comment Share on other sites More sharing options...
Richard Choi Posted June 29, 2007 Report Share Posted June 29, 2007 Has this problem existed pre 1.7 or in previous betas? I have found the cause of this issue, and it appears most peculiar. Link to comment Share on other sites More sharing options...
Firon Posted June 30, 2007 Report Share Posted June 30, 2007 This was a problem that's supposed to have been fixed several times (probably since 1.5 or something), but it seems like it hasn't still. Link to comment Share on other sites More sharing options...
Ultima Posted June 30, 2007 Report Share Posted June 30, 2007 I actually remember it supposedly being fixed long before that... All the way back in 2005 even, if memory serves me correctly. Link to comment Share on other sites More sharing options...
Ryan Norton Posted June 30, 2007 Report Share Posted June 30, 2007 It is a limitation (well... behaviour) of the Windows "save as..." dialog - it checks to see whether the file is writable. The trick is that when you specify "skip hashcheck" it uses the "open" dialog.EDIT: Only a limitation if you have it validate the path... which we do ourselves anyway Link to comment Share on other sites More sharing options...
Ultima Posted June 30, 2007 Report Share Posted June 30, 2007 Interesting workaround... Of course, if you use that, you should force a recheck afterwards just to be sure. Link to comment Share on other sites More sharing options...
Richard Choi Posted July 3, 2007 Report Share Posted July 3, 2007 We've submitted a fix for this in the next build. Link to comment Share on other sites More sharing options...
funchords Posted July 4, 2007 Author Report Share Posted July 4, 2007 Thanks Richard -- I'll be back to let you know. I appreciate the late change! Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.