Linux Lite 7.2 RC1 Released

[stevef]

OK.  I can reproduce the problem consistently on 7.2RC and 7.0.
Not yet tried on 6.x or 5.x
The 7.0 system has had a few look and feel tweaks, but the 7.2RC is just as installed.

I have not seen a problem using the default location for Save Updates Log as  a file.
The problem occurs if making a custom directory for the location using the tool.

At the end of the Lite Update tool process click 'Yes' to view the log.
Click 'Save'
Click the 'Create Folder' button in the upper right of the 'Save Updates Log' window.
Call the new folder 'Logs' and click 'Create'
Click 'OK'
The save dialog window closes silently.

The 'Logs' directory gets made in the home directory, running ls -l suggests it is owned by root.
Running ls in the 'Logs' directory shows it to be empty.

Can provide screenshots if necessary.

[Valtam]

I'll try with those steps, thanks for providing.

[Şerban S.]

[...] The problem occurs if making a custom directory for the location using the tool. [...]  directory shows it to be empty.

Hi!

I was able to reproduce the bug.
To be sure, I made a low level backup and I've tested twice, with another name for the dir: "TestLog". Same as before. Owner is Root and is empty.

I explained in a previous post what I thought has happened:


"I will check at the next update to see if I use the Lite Dialog if this goes as "root". As far as I remember, this is possible since the MkDir is issued from inside the script and it used "sudo apt  install *". Since the persistence of the Root session is long enough to allow the updates, we can have an answer here.

The only way out in this case, is adding a ChOwner after the Dir creation and before saving the file. A delay before the save instruction might also be necessary to allow the system to update the directory structure and prevent the "File Missing" error.
Also, invoking "SaveAs" dialog as Root (this is the case as I see it), will generate a chain of Root processes, hence the Dir owner is Root and the file owner is also Root."

What is difficult to explain is why all goes as expected, if another path is chosen and the MkDir is skipped.
At my first attempt, I used "/video/FileName.txt". Nothing fancy.
The difference is that the owner of "/video/" is "serban" (me) and I only saved the file. I guess I need to test again if I use the same partition but I invoke the "Create Directory" dialog, will result in a Root owned directory as well.
If the string parameter passed when invoking the Dialog contains "$USER", at that point, the contents of "$USER" is "root". Thus the MkDir will create the root owned whatever (file, directory).
The abnormality is that even so, the file should be saved. That means that somewhere along the code, the contents of a path variable is deprecated (remains the default one) in which case we get a WriteFile error which instead of rising the error message, goes unnoticed.
However, if the SaveAsDialog call exits, it should return an ErrorCode = whatever. Usually 0 if success.
If the ErrorCode is checked, than all should go as expected. Maybe this line of code is missing.
A nested conditional should check the return value of the function and branch accordingly.
If this step is skipped, the code goes on the default path (save the file in the default path) instead of retaining the new data. 
The syntax of the procedure should make the options clear in both cases (SaveAs or CreateDir).
This is as far as I could get.
Is it possible that the "Save As..." dialog is re-launched in a different line of code if instead of saving the file we choose to create a new directory?
Depending on the specific implementation of the "SaveAsDialog" function (procedure?), it is possible to go to another line of code that re-launches the Dialog with another flag (parameter) in this case might be something like boolCreateDir and the class will generate another window (Create Directory) and this is owned by Root, thus any created directory will inherit the attributes.

Bestb regards, Șerban.

[stevef]

The permissions problem is on 5.x and 6.x as well as 7.x
Ran the command from CLI to collect the error messages across three versions.
Followed the GUI process as described above and created a new folder on each set up.
In each case the new folder was owned by root and empty
Ignore the sed and awk messages.  Both the 5.8 and 6.6 systems have the long standing Lite Updates 'silent update' problem so have extra messages.
The sed and awk errors occur during the 'silent update' bit, the cp error is thrown when saving the log.

LL 7.2RC

Code:

stephen > ~ > /usr/bin/lite-updates

cp: cannot create regular file '/home/stephen/UpdateLog/llupdates-Monday-30-September-2024-19:24:23.txt': Permission denied
 stephen > ~ > 

LL 5.8

Code:

 stephen > ~ > /usr/bin/lite-updates
sed: couldn't open temporary file /etc/sedrjpVOM: Permission denied
awk: cmd. line:1: (FILENAME=- FNR=10) fatal: division by zero attempted

File does not exist
cp: cannot create regular file '/home/stephen/Logs/llupdates-Monday-30-September-2024-19:36:46.txt': Permission denied
 stephen > ~ > 

LL 6.6

Code:

 stephen > ~ > /usr/bin/lite-updates
sed: couldn't open temporary file /etc/sedxdZp63: Permission denied
awk: cmd. line:1: (FILENAME=- FNR=10) fatal: division by zero attempted

File does not exist
cp: cannot create regular file '/home/stephen/Log/llupdates-Monday-30-September-2024-19:32:12.txt': Permission denied
 stephen > ~ > 

[Valtam]

Thanks again steve, I've got Huzaifa looking into this.

[Valtam]

Huge thank you to Huzaifa for fixing this bug, took us a long time to work through it. Thanks also to stevef for reporting it. Lite Updates to get the new package.