Overwriting an existing package fails using Drop path

[Nir]

Hi
I am using LDAP authentication enabled- the proget service is running using a service user, which is granted "contributor" Role which has the Feeds_OverwritePackage privilege set.

When placing a modified package which already exists in the feed under the drop path, this package doesn't get pushed to the feed and doesn't overwrite the old package.
The following message is shown in the errors under administration:
The package xxx already exists and the current user or service does not have the Feeds_OverwritePackage privilege.

Stack Trace:
at Inedo.ProGet.Packages.NuGetFeed2.InstallOrUpdatePackage(Stream stream, Boolean calculateHash, Boolean cached, Boolean install, Boolean overwrite, Nullable`1 publishDate)
at Inedo.ProGet.Packages.NuGetFeed2.InstallPackage(Stream stream, Boolean allowOverwrite)
at Inedo.ProGet.Service.DropPathMonitorExecuter.ImportNuGetFeed(NuGetFeeds_Extended feed)

When trying to manually upload this package from the Web UI, (without using the drop folder) - using the same service user logged in - it succeeds

Product: ProGet
Version: 3.6.1

[Dean]

This is actually by design, though the logged message could be better. Since drop path imports happen in the background, we didn't want ProGet to ever silently overwrite packages in a feed; therefore overwriting isn't currently allowed from a drop path import.

If this is important for you, we could add a configuration option to control this behavior in a future version.

[Nir]

This configuration would be highly useful for us, as we rely on the option to drop files (even if they exist already we overwrite them) for adding/modifying packages as part of the build process.
Any idea when could this option be available for use?

Thanks
Nir

[Tod]

We could probably add this to the next maintenance release. Anyway, is there something preventing the build process from using the nuget.exe client to PUSH the package instead of dropping it in the bulk import path? That way you'd have full control of the privileges used to push.

[Nir]

We could do that or think of other workarounds, but the thing is that this change is breaking our current process, in the previous version copying the file to the unc path would do it - which is what many build scripts we have are doing - if we have a lot of packages as part of the build - doing a nuget push sometimes takes longer than just copy.
As I said, we can think of solutions for this, but before we do - I wanted to understand when can we expect a fix for this change in behaviour

Thanks
Nir

[Dean]

We've already added this option internally; we'll likely release a 3.6.2 with this and a few other fixes some time later today.

[Nir]

Thank you very much guys for pushing this feature to the last release.
I've upgraded our server today, turned the option on, and it works great.
Cheers.