Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Can't create/write to a LOG file on a server box. 2

Status
Not open for further replies.

IlyaRabyy

Programmer
Nov 9, 2010
566
0
16
US
Colleagues,
I've made a small program that checks the files' sizes in a "target" directory (too large image files, like clients' logos, may cause problem with printing docs).
This Program works perfectly on my WS: sends E-Mail alerts and writes the findings into LOG file w/o any problem.
However, when I posted this program (EXE and INI files) on a server - Program works, that is sends alerts, but does not create this LOG file.
I checked the User Access permissions - Read/Write/Execute, so it's not like a User has just Read/Execute privileges, and still...
I even ran this EXE As Administrator - same thing: no LOG file was created/updated.
Here's the code:
Code:
Public gsStartDir As String = (System.IO.Path.GetDirectoryName(System.Reflection.Assembly.GetExecutingAssembly().Location)).Replace("\bin\Debug", "\")
Public gsLog As String = "", gsLogFile As String = gsStartDir & "Image_File_Size_Control.LOG"

'...

gsLog = Replicate("=", 134) & vbCrLf & "Server/WS Name: " & Environment.MachineName & vbCrLf & vbCrLf & "Start DateTime: " & Format(Now, "yyyy-MM-dd HH:mm:ss") & vbCrLf & _
[indent][indent]Replicate("=", 134) & vbCrLf[/indent][/indent]
[b]My.Computer.FileSystem.WriteAllText(gsLogFile, gsLog, True)[/b]

There are other places where this statement on the bottom of the code is used.
So, the Question is: What prevents the Program's writing onto server's HDD, even if the User has all but Admin privileges?
OR: what am I doing wrong?

Please advise!

Regards,

Ilya
 
What's the value of [tt]gsLogFile[/tt] and does it exist on the Server?

---- Andy

"Hmm...they have the internet on computers now"--Homer Simpson
 
>System.IO.Path.GetDirectoryName(System.Reflection.Assembly.GetExecutingAssembly().Location)

Are we sure this works as expected on the server?

 
Andrzejek said:
(1) What's the value of gsLogFile and (2) does it exist on the Server?
(1)[EXE's location directory]\Image_File_Size_Control.LOG
(2) The Program is supposed to create this LOG file if it doesn't exist - it does on my WS and does not on the server.
Even if this LOG file does exist (copied from my WS) - the Program doesn't write into this file.

strongm said:
>System.IO.Path.GetDirectoryName(System.Reflection.Assembly.GetExecutingAssembly().Location)
Are we sure this works as expected on the server?
I am: it worked with my other two programs on the same server box. Especially the other Program that creates XML files on that same server box.

I have to tell you, it's the 1st time I hit this "roadblock" in the last 20+ years! Last time my program couldn't write on disk was when client's Sys Admin restricted all Users (but himself) to just Read/Execute access rights. Which is not the case here.

So, right now, I'm at total loss and out of ideas. [sadeyes]

Regards,

Ilya
 
I would definitely try (while testing your app on the Server):

Code:
...[blue]
MessageBox.Show(gsStartDir)
MessageBox.Show(gsLogFile)[/blue]
My.Computer.FileSystem.WriteAllText(gsLogFile, gsLog, True)

---- Andy

"Hmm...they have the internet on computers now"--Homer Simpson
 
>but does not create this LOG file

But from the way you describe it you don't get an error message. Which suggests that the file is being written, just not where you expect it to be written (for example a quick examination of your code suggests you might want to have a look in the parent of the folder you think the log should be written in).

>(1)[EXE's location directory]\Image_File_Size_Control.LOG
and
>>System.IO.Path.GetDirectoryName(System.Reflection.Assembly.GetExecutingAssembly().Location)
>>Are we sure this works as expected on the server?
>I am

Perhaps not. See above ...

If you are getting an error message, on the other hand, perhaps you could share it in detail
 
Colleagues,
You were both right: this statement
Code:
gsStartDir As String = (System.IO.Path.GetDirectoryName(System.Reflection.Assembly.GetExecutingAssembly().Location)).Replace("\bin\Debug", "\")
on my WS produced the path ending with the backslash, "C:\Ilya_Docs\Projects_and_Programs\VS_2019_Projects\Image File Size Control\", but on the server it was "D:\Program Files\...\Image File Size Control" w/o backslash. That LOG file was created in the root dir instead of the start dir.
I enforced backslash at the end of the gsStartDir

Code:
gsStartDir As String = [u]AddBackSlash([/u](System.IO.Path.GetDirectoryName(System.Reflection.Assembly.GetExecutingAssembly().Location)).Replace("\bin\Debug", "\"))

and it started working as it's supposed to.
Thank you both for your help!

P.S. Just in case you're wondering, here's this function AddBackSlash() (mimics built-in ADDBS() in VFP)
Code:
'===================================================================================================================================
Public Function AddBackSlash(ByVal tsPath As String) As String
'===================================================================================================================================
' Purpose       : Ensures the given path string has backslash at the end.
' Description   : Checks if the passed parameter's data type match those of the Function's argument; if not – throws error message 
'                 and returns unchanged parameter.
'                 Checks if it's an empty string, if it is - returns it As-Is.
'                 Checks if it's only a file name, if it is - returns it As-Is.
'                 Checks the given parameter-string in case it's full path to a file, cuts off the file name if it is.
'                 Checks if the given parameter-string has backslash at the end, adds it if it has not.
' Parameters    : Path as String - mandatory
' Returns       : Path with the backslash at the end, as String.
' Side effects  : None.
' Notes         : 1. Generic, applies with .NET Framework ver. 1.1, .NET Core 1.0, .NET Standard 1.0 and higher.
'                 2. Verbose on errors, silent otherwise.
' Author        : Ilya I. Rabyy
' Revisions     : 2020-03-09 by Ilya – started 1st draft.
'===================================================================================================================================
Dim lsPath As String = "", lsRet As String = ""

' Parameter's verification
If VarType(tsPath) <> VariantType.String Then
	MsgBox("Invalid parameter passed: " & Chr(34) & "tsPath" & Chr(34) & " must be of type String", MsgBoxStyle.Critical, "Fatal Error: INVALID PARAMETER")
	Return lsRet
End If

If String.IsNullOrEmpty(tsPath) Then
	Return lsRet
End If

If Path.GetFileName(tsPath) <> "" And Path.GetExtension(tsPath) <> "" Then 'Path + File name? Strip off that latter
	lsPath = tsPath.Replace(Path.GetFileName(tsPath), "")
Else
	lsPath = tsPath
End If

If String.IsNullOrEmpty(lsPath) Then ' Only the file name was passed? Return blank string
	Return lsPath
End If

' Check for the closing backslash
If Strings.Right(lsPath, 1) <> Path.DirectorySeparatorChar Then
	lsRet = lsPath & Path.DirectorySeparatorChar
Else
	lsRet = lsPath
End If

Return lsRet
End Function
'===================================================================================================================================

Regards,

Ilya
 
>Just in case you're wondering ... AddBackSlash(

.net has built-in methods to do this sort of thing ...
 
strongm (MIS) said:
.net has built-in methods to do this sort of thing ...
Apologies, but couldn't find any...
Would you be so kind to point on it for me?

Regards,

Ilya
 
Ok, so first question - why do you want to add the backslash?

The main reason is usually to ensure we have a seperator when we add another path element or a filename in that path. But in that case why not use Path.Join? It'll correctly add all necessary separators
 
strongm (MIS) said:
The main reason is usually to ensure we have a separator when we add another path element or a filename in that path.
Absolutely correct!
And since the path is often typed into a TextBox by a User or, like in my case, returned by some system's function, the closing backslash can be (and was, in my case) missing/omitted/dropped.
Thus, the "insurance" in the form of the "forced" backslash at the end is needed.
The same is true for automatic/programmatic reading from a client-provided text/data files. (I learned it the hard way, way back when!)
So, Path.Join() is not applicable in cases like those described above, when I need just the path.
Enters ADDBS() in Visual FoxPro (23+ years of experience by yours truly), which I mimicked here.
Thus, I eliminate, right from the start, the headache of not knowing whether there's backslash at the read/User-entered path or not.
Besides, typing just lsPath2File = gsSrcDir & lcFilNam is faster than typing lsPath2File = Path.Join(gsSrcDir, lcFilNam) by 9 keystrokes! :)
Me's no trying to diminish the value of Path.Join() by any means, just MHO. :)

Regards,

Ilya
 
> faster than typing lsPath2File = Path.Join(gsSrcDir, lcFilNam) by 9 keystrokes!

Ha! Sure - but for that to work at some point you will have had at some point to

[tt]gsSrcDir = AddBackSlash(gsSrcDir)[/tt]

... 32 additional keystrokes ...

But my point really was that you can let .net do the heavy lifting for you. For example, your AddBackSlash function could be rewritten as:

Code:
 [COLOR=blue]   Public Function AddBackSlash2(ByVal tsPath As String) As String
        AddBackSlash2 = Path.Join(tsPath, ".").TrimEnd(".")
    End Function[/color]

(this version has the advantage that it fixes the issue you are encountering in thread1867-1821131)
 
strongm (MIS) said:
let .net do the heavy lifting
Tried that.

2023_04_13_09_03_Path_Join_IsNotInNET_4_8_jfxw8j.jpg


Join() is not in .NET 4.8 I'm working with on this Win Forms project:

2023_04_13_10_44_Only_NET_4_8_For_ASCII_Text_Search_rp7jk8.jpg


It is present in .NET starting from ver. 5.0, though, this is why I didn't get this error when tested it in a stand-alone module:

2023_04_13_10_51_Common_Subs_Functions_p17zcj.jpg


And even .NET 5.0 is out of support already...

Any suggestions (aside from installing .NET 6.0)?

Regards,

Ilya
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top