# \[F\] Inefficient free space checking

**URL:** https://community.mp3tag.de/t/f-inefficient-free-space-checking/13690
**Category:** Fixed Bugs
**Created:** [July 26, 2012, 12:36pm UTC](https://community.mp3tag.de/t/f-inefficient-free-space-checking/13690 "2012-07-26T12:36:49Z")
**Posts on this page:** 4
**Page:** 1

<div class="post-metadata">

### Author: ![I.M.Jens](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/i/0ea827/32.png) [@I.M.Jens](https://community.mp3tag.de/u/I.M.Jens)
#### Post date: [July 26, 2012, 12:36pm UTC](https://community.mp3tag.de/t/f-inefficient-free-space-checking/13690/1 "2012-07-26T12:36:49Z")

</div>

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

---

<div class="post-metadata">

### Author: ![ohrenkino](https://community.mp3tag.de/user_avatar/community.mp3tag.de/ohrenkino/32/4843_2.png) [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [July 27, 2012, 3:47am UTC](https://community.mp3tag.de/t/f-inefficient-free-space-checking/13690/2 "2012-07-27T03:47:24Z")

</div>

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?

---

<div class="post-metadata">

### Author: ![I.M.Jens](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/i/0ea827/32.png) [@I.M.Jens](https://community.mp3tag.de/u/I.M.Jens)
#### Post date: [July 29, 2012, 11:48am UTC](https://community.mp3tag.de/t/f-inefficient-free-space-checking/13690/3 "2012-07-29T11:48:51Z")

</div>

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 GetDiskFreeSpace **Ex** API call ([_Syntax - MSDN_](http://msdn.microsoft.com/en-us/library/windows/desktop/aa364937(v=vs.85).aspx)) 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:

```
#if WINVER 0501
  <i>GetDiskFreeSpace<b>Ex</b>(...)</i>
#else
  <i>GetDiskFreeSpace(...)</i>
#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.

---

<div class="post-metadata">

### Author: ![Florian](https://community.mp3tag.de/user_avatar/community.mp3tag.de/florian/32/5759_2.png) [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [December 28, 2018, 2:06pm UTC](https://community.mp3tag.de/t/f-inefficient-free-space-checking/13690/4 "2018-12-28T14:06:32Z")

</div>

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
