2

The goal I have is simple: From a web app, write to a folder on the D drive of a local server. When I run the code locally (in the debugger) it writes to the folder beautifully. When I publish the code to the web server it cannot see its own D drive, or shared folder. I have tried every permutation of the file path string I can imagine, including absurd ones.

Examples:

filepath = "\\\\wsbliwad\\d\\Payroll\\PaperlessPay";
filepath = "\\wsbliwad\\d\\Payroll\\PaperlessPay";
filepath = "\\wsbliwad\d\Payroll\PaperlessPay";
filepath = "\\\\wsbliwad\\Payroll\\PaperlessPay";
filepath = "\\wsbliwad\Payroll\PaperlessPay";
filepath = @"\\wsbliwad\payroll\PaperlessPay";
filepath = @"\\\\wsbliwad\\payroll\\PaperlessPay";
filepath = @"\\wsbliwad\\payroll\\PaperlessPay";
filepath = @"\\wsbliwad\d\Payroll\PaperlessPay"

... and a host of others as well.

Using Response.Write statements to get a sense of what's happening, if I run the code locally, I get the following feedback:

Path one = \\wsbliwad\payroll\PaperlessPay
Exists = True
Path two = \\wsbliwad\\payroll\\PaperlessPay
Exists = True
Path one = \\\\wsbliwad\\payroll\\PaperlessPay
Exists = True
Host Name is CPU1476
AD User is ANVILCORP\DGray

And the file writes to the folder.

When I deploy that same code, I get a failing result:

Path one = \\wsbliwad\payroll\PaperlessPay
Exists = False
Path two = \\wsbliwad\\payroll\\PaperlessPay
Exists = False
Path one = \\\\wsbliwad\\payroll\\PaperlessPay
Exists = False
Host Name is WSBLIWAD
AD User is ANVILCORP\dgray

No file is written.

I've gone to the folder and explicitly granted write permissions to all the users in our group who need it, thinking perhaps it was a badly reported permissions issue. No such luck.

One oddity I have noted is that the last line in my response.write gives me upper case letters for the domain user when I run it in the debugger, and lowercase when the code is deployed. I don't know that it should matter, but it does seem odd.

Any ideas why the code can see the shared folder from my debugger, but not when deployed?

For DJ KRAZE'S request below:

protected void btn_Export_Click(object sender, EventArgs e)
{

    DateTime mCheckDate = DateTime.Parse(tb_CheckDate.Text);
    int mPeriod = Int32.Parse(tb_Period.Text);


    try
    {
        string checkDateFormat = "MM/dd/yyyy";
        ReadOnlyCollection<IDataRow> dataRows = FlatFileExportWeb.PaperlessPay.GetPaperlessPayData(mPeriod.ToString(), mCheckDate.ToString(checkDateFormat));

        if (dataRows == null)
            return;

        IDataFormat format = new SimpleDataFormat(dataRows);

        string filepath = "";
        string machineName = System.Net.Dns.GetHostName();               
        if (machineName == "WSBLIWAD")
        {
            // This path does not work
            filepath = @"\\wsbliwad\d$\Payroll\PaperlessPay";
        }
        else
        {
            // this path works when debugging
            filepath = @"\\wsbliwad\payroll\PaperlessPay";
        }

        string filename = "PaperlessPay" + mCheckDate.ToString("MMddyyyy") + ".txt";

        new FileGenerator(filepath, filename).BuildFile(format);
        Response.Write("<br />&nbsp;&nbsp;&nbsp;Success!! The flat file has been written to " + filepath + @"\" + filename);
    }
    catch (Exception ex)
    {
        // Display any exceptions that may have been thrown.
        System.Web.HttpContext.Current.Response.Write(ex);
    }
}

... and then...

// Absolute path with concatenated filename
string mFilenameWithPath;

/// <summary>
/// Constructs a FileGenerator instance pointing to filepath\PaperlessPay\filename.
/// Will delete pre-existing file at this location.
/// </summary>
public FileGenerator(string filepath, string filename)
{
    if (!Directory.Exists(filepath))
        throw new DirectoryNotFoundException(filepath);

    mFilenameWithPath = filepath + @"\" + filename;

    if (File.Exists(mFilenameWithPath))
        File.Delete(mFilenameWithPath);
}


/// <summary>
/// Given an IDataFormat instance, BuildFile builds an output string.
/// It will then write this output string to the file specified within
/// the class, as passed into the constructor.
/// </summary>
/// <param name="format"></param>
public void BuildFile(IDataFormat format)
{
    // Make sure the format exists
    if (format == null)
        return;

    // Collect output string, and
    // write the string to filepath.
    using (StreamWriter writer = File.CreateText(mFilenameWithPath))
        writer.Write(format.Build());
}
DJGray
  • 504
  • 8
  • 26
  • Which user does IIS run as on your destination server? – Adrian Wragg Aug 02 '13 at 13:37
  • when doing directory paths over network you need to utilize the `$` in your file path for example `\\servername\c$\FolderName` `Servername\DriveName\FolderName` home that makes sense if you are doing this via web application you should look at `MapServerPath` – MethodMan Aug 02 '13 at 13:37
  • 1
    @DJKRAZE Not for named shares, you don't; that's only for the administrative shares of C:, D:, etc. The '$' just means that it's hidden from anyone browsing. – Adrian Wragg Aug 02 '13 at 13:39
  • @DJGray Why are you using a UNC path for talking to the local drive in the first place? – Adrian Wragg Aug 02 '13 at 13:41
  • If you are wanting to write to a directory you could also do something like the following `File.WriteAllText(Server.MapPath("~/PaperlessPay/SomeData.txt"), "Some Text to store in the File");` since you said web application perhaps you need to setup virtually directory for my last example to work – MethodMan Aug 02 '13 at 14:00
  • show the portion of code that you are using please – MethodMan Aug 02 '13 at 14:01
  • Thank you for all the interest in helping get this resolved. I'll post the relevant code section in a moment as DJ KRAZE has asked. This is IIS 7. – DJGray Aug 02 '13 at 14:09
  • DJ KRAZE, can I use Server.MapPath to point to a different drive? The shared folders are on the D drive. – DJGray Aug 02 '13 at 14:47
  • New Information: I have found that if I search for @"\\wsbliwad\payroll" that folder is found. It is only when I search for @"\\wsbliwad\payroll\PaperlessPay" that I throw the exception. Does this lead me back to a permissions issue? I see the users explicitly granted access to the folder when I view its properties. – DJGray Aug 02 '13 at 16:58
  • 1
    yeah - this still sounds like a permission issue. – traxs Aug 02 '13 at 17:11
  • Traxs, since I'm an administrator on the machine, and I have granted myself write permissions to both folders, and I belong to the AD group that has write permissions to the folder, what should I look for to correct the permissions issue? Also, does it help resolve this to remember that it works when I run it in the debugger, but not when it is deployed to the web server? – DJGray Aug 02 '13 at 17:22

3 Answers3

3

Have you tried

 @"\\wsbliwad\d$\Payroll\PaperlessPay"

?

traxs
  • 306
  • 1
  • 5
  • No, and that was an excellent suggestion. Unfortunately, I'm still getting the DirectoryNotFoundException. – DJGray Aug 02 '13 at 13:51
  • 1
    Hrm - It sounds like a permission issue. The user IIS is running as does not have permission to that folder. – traxs Aug 02 '13 at 14:12
  • Traxs, I had that thought as well, which is why I mentioned above that I explicitly granted permission to the five people who need access to these folders. It was redundant, because they are already in AD groups and the groups have write permissions to the folder. It would seem that I'd get a different error message, but again, I'm trying everything I can imagine in order to get this to work, and permissions was one of the things I imagined... – DJGray Aug 02 '13 at 14:35
1

Traxs is correct. It did indeed turn out to be a permissions issue. We are interfacing two systems, and created a domain account named Interface.Dev. That user was listed in the security properties with write permissions, but for some reason needed Full Control rather than Write.

Thanks Traxs for persistently pointing me down that path. The error message was TERRIBLY misleading, and I would have continued fighting with the path information for an eternity otherwise.

DJGray
  • 504
  • 8
  • 26
1

It may be because you do not have write access to that path.

SaraNa
  • 76
  • 4