IPB

Welcome Guest ( Log In | Register )

> Notice!

Please take a minute to check our Frequently Asked Questions. Use Search to reveal possible related topics.

Also make sure you've read the Forum Guidelines before posting in this forum.

Abbreviations: (will be specified by moderators/administrators)





[X]No Bug[C]Confirmed Bug Report
[F]Fixed Bug[LP]Low Priority Bug Report
[AF]Awaiting Feedback

 
Reply to this topicStart new topic
> Inefficient free space checking
I.M.Jens
post Jul 26 2012, 15:36
Post #1


Member


Group: Members
Posts: 2
Joined: 26-July 12
Member No.: 16723
Mp3tag Version: 2.52



Hi,

I really love this program but I always have a problem with saving changes of larger files.

I'm accessing my files through junction points on a very small drive (40MB total / 10MB free) (this overrides the drive letter and path length limitations).
The trouble now is, while mp3tag is checking the free space of the drive of the path it's impossible to save files larger than those 10MB though the actual location has more than enough free space. An old workaround was to access these files directly on their 'residential' drive but sometimes the paths become too long and meanwhile I ran out of letters.

I think a better way might be to check the free space of the directory itself where the file is located (not the start directory as possible sub directories might have different locations!). This would also eliminate complications with disk quotas.

Thanks.
Jens
Go to the top of the page
 
+Quote Post
ohrenkino
post Jul 27 2012, 06:47
Post #2


Member


Group: Full Members
Posts: 4788
Joined: 9-December 09
From: Norddeutschland / Northern Germany
Member No.: 11458
Mp3tag Version: 2.65a



Mp3tag relies on the information that is reported by the operating system.
So: what does your OS say about the target location?
The "old workaround" BTW, is not a workaround but the only legal way to use network locations just like drives.
Network folders behave differently than ordinary folders. E.g. you cannot execute a chkdsk and usually the "trash" does not keep files from network folders.
So, how do you think should MP3tag alter the OS behaviour, or, in other words: where is the MP3tag bug if it is the OS?


--------------------
42 - wie war die Frage / what was the question / comment était la question
Go to the top of the page
 
+Quote Post
I.M.Jens
post Jul 29 2012, 14:48
Post #3


Member


Group: Members
Posts: 2
Joined: 26-July 12
Member No.: 16723
Mp3tag Version: 2.52



Actually the bug is the way this information is retrieved:

I presume you are using the GetDiskFreeSpace API function (or the tool/library you are using) which just accepts the root folder of a (local) drive. But a GetDiskFreeSpaceEx API call (Syntax - MSDN) is focused on the directory of the given path and if the path points to a symbolic link (reparse point) the target will be evaluated.
Of course this will not work on OS's prior to WinXP as they don't support reparse points!

Maybe you should program a pre-processor clause to keep compatibility with prior windows versions:

CODE
#if WINVER 0x0501
GetDiskFreeSpaceEx(...)
#else
GetDiskFreeSpace(...)
#end if


So it's not a problem of the OS.

I hope this can help. If you prefer to regard this as a development proposal, I don't care. But I would be thankful if this issue could be solved.
Go to the top of the page
 
+Quote Post

Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 1st November 2014 - 00:43