Get device memory information

[opeolluwa]

To resolve this issue,

1. Refactor the system memory module to
   return the following information correctly:

• total available memory
• used memory
• device battery uptime in hh mm (hour and minutes)

2. Write unit test(s) for the implemented logic.

[zoo868e]

Hi Opeoluwa, I would like to give solving this issue a try.

[opeolluwa]

Hi @zoo868e thanks for reaching out ❤️ I'd assign the issue to you. Let me know if you have any questions

[zoo868e]

Hi @opeolluwa, I would like to define the details about these feature requests.

Refactor the structure that includes the informations.

• Available memory. It takes into account the amount of memory that can be made available by reclaiming various resources, such as page caches, that can be used by applications if necessary.

• Used memory. We can calculate the used memory by subtracting the free memory, which represents the memory that is not being utilized, from the total memory.

• Device battery uptime in hh mm. In the current implementation, the uptime is counted in seconds. Are you suggesting that the resulting uptime should only be expressed in hours and minutes? For example, using the format "12 25" to indicate that the device has been up for 12 hours and 25 minutes? I personally prefer a more detailed and clear declaration, such as "1 year, 11 months, 2 days, 1 hour, 7 minutes, and 30 seconds."

[opeolluwa]

The first one,
Memory Information : Get the memory capacity of the device and the used memory. This will be used for checking for insufficient storage during file transfer

[opeolluwa]

Device battery uptime in hh mm before each transfer, the battery uptime will be checked to inform the user of the likelihood of incomplete transfer due to device power outage

[opeolluwa]

I hope these answers the questions, let me know if you need more clarification

[zoo868e]

Hi @opeolluwa, in relation to the uptime, I believe the information about whether the device will run out of power or not can be determined. I think it would be more useful to include the device's charging status and the remaining battery time as additional information.

[opeolluwa]

Hi @opeolluwa, in relation to the uptime, I believe the information about whether the device will run out of power or not can be determined. I think it would be more useful to include the device's charging status and the remaining battery time as additional information.

Here's what I intend to do, once the average transfer rate and the device uptime is known, an estimate of the time it will take to transfer the file can made.

Supposed the transfer rate is 100MB/min and I'm sending a 1.2GB (1200MB, approximately) file, all thing being equal, the transfer should be completed in 1.2min, if the device uptime is at 0.8 min, the application should prompt user to charge device.

[opeolluwa]

Basically, this issue focuses on getting the uptime. At the core(Rust code), the implementation was initially provided in seconds, to allow ease of interconversion

[opeolluwa]

@zoo868e it would be great if you could implement the charging status, also by the device uptime, I mean the battery uptime which would mean the same thing as you pointed out

[opeolluwa]

Hi @zoo868e, how is it going?

[zoo868e]

Hi @opeolluwa , I'm trying to mock the structure for unit test.

[opeolluwa]

Alright, well done. And thank you so much for your time and effort ❤️

[zoo868e]

Hi @opeolluwa, I have sent the pull request #154 . Thank you for waiting.

[opeolluwa]

Hi, @zoo868e I think there might be a bit of a glitch in this solution.
First of, I'm thankful for your ending effort and dedication to build this. I do appreciate it ❤️

I ran the test again on my machine, I got the following results.

[opeolluwa]

The available memory returned is 2MB in place of 8.7 GB and 116 MB in place of 124.9 GB. It could be an OS compatibility issue. Please let me know if all works fine at your end

[zoo868e]

Hi @opeolluwa , thanks for finding, let me check it

[zoo868e]

I have reviewed the source code of the crate used to retrieve Linux disk information, and I found the following pseudocode:

1. Read the file /proc/mounts.
2. Filter out devices whose names do not start with /dev/ or /dev2/.
3. Filter out devices that are in read-only mode.
4. Filter out devices whose names contain the character :.
5. Filter out devices of type smbfs that start with //.
6. Filter out devices of type nfs, autofs, gfs, or none.
7. Obtain disk information using statvfs, which provides information about a mounted filesystem.

However, based on the implementation, it appears that the code returns the total space of all mounted disks. For our specific project, we need to focus on a specific device from which we will download files and verify if that device has sufficient space. Therefore, I will implement a function that can retrieve disk information for a specific mounted filesystem.

Indeed, to obtain the disk information for a specific device, we will need to pass the device name as a parameter to the new function. Considering that the project aims to support various platforms, it is necessary to have platform-specific implementations.

[opeolluwa]

All noted, thanks for taking your time to look at this again! I appreciate your time and effort ❤️

[opeolluwa]

Hi @zoo868e, any fix?

[zoo868e]

Hi @opeolluwa, I have tested the function on my laptop and it appears to be working incorrectly as well. I am considering finding alternative crates to sys_info. Another option would be to implement our own library for retrieving system information. However, I believe this would be a significant project as it would need to be implemented cross-platform.

[zoo868e]

Furthermore, if we decide to implement our own library, I suggest focusing on retrieving the disk information of each device instead of just the total space. This is because we may not know the specific path where the file will be downloaded, and having information about individual disks would provide more flexibility.

[opeolluwa]

I'd look into a custom library to do this...

[opeolluwa]

See this conversation on Reddit, it might help out https://www.reddit.com/r/rust/comments/o757bv/is_there_a_way_to_get_a_list_of_storage_devices/?utm_source=share&utm_medium=android_app&utm_name=androidcss&utm_term=1&utm_content=share_button

[opeolluwa]

Furthermore, if we decide to implement our own library, I suggest focusing on retrieving the disk information of each device instead of just the total space. This is because we may not know the specific path where the file will be downloaded, and having information about individual disks would provide more flexibility.

Files are uploaded to a "sendfile" in the OS default download path.

See implement here

[opeolluwa]

The library I'd be writing would retrieve the size and available storage information of the storage media, on which the default download dir is.

What do you think of this

[zoo868e]

Well done! 💯 I think it has solved this issue! I think the structure of Drives can be a part of SystemInformation.

[opeolluwa]

I'd be writing exams over the next few weeks, I might not have enough time to fix the issue, but I'd certainly look into it as soon as I'm done with the exams and I'd be available to attend to questions you might have

[zoo868e]

Hi @opeolluwa, I replaced sys_info with sysinfo, and it appears to be functioning correctly on Windows. Could you please test it when you have some time? #203

[opeolluwa]

Hello @zoo868e I'd look into that, thank you for reviewing it

[zoo868e]

Hi @opeolluwa, I have implemented a new function (#204) in the SystemInformation module that returns the available space of a specific disk based on the provided folder name. Could you please test it when you have some time? I have tested it on Windows, but the format of folder/mount point in Unix-like systems may differ.

[opeolluwa]

Hi @zoo868e this works fine. Is there any refactoring you'd like to make or I can close the issue

[zoo868e]

No, please close the issue. Thank you.

[opeolluwa]

Solved