libntfs_ext library compilation with cellsdk

[bguerville]

Almost, all of them in the file manager. As you can see in the sample there is several way to mount NTFS, managunz is using ntfsmountAll because it's simpler. I'm using standard function to have only one uniform write for FAT32 and NTFS.

That's what I thought & as ntfs support has to be brought to the wMM file manager among other things I expect all the library functions will be used in wMM too..
Standard functions will have to be used too in wMM for both fat32 & ntfs support..

 

[Zar]

you didn't understand. It was convenient for me to use standart function but we can do without it, like it's done in iris for example...

for example if i open a file I can do this for NTFS and FAT32 :

f=fopen(file_path, "rb");​

But if i don't use standart function I have to "detect" if i'm in NTFS or FAT32 :

if( strstr(file_path, "ntfs") ) {

f = ps3ntfs_fopen(file_path, O_RD, 0777);​

} else {

f = sysFsOpen(file_path, ORD, 0777);​

}​

Understood ? anyway, webMAN MOD don't need it, trust me.

 

[bguerville]

you didn't understand.
...
Understood ? anyway, webMAN MOD don't need it, trust me.

Thanks for the details but I had already understood perfectly.
And of course it's not mandatory but I still think that it may be easier to use it in some of wMM's features.
It's obviously not needed to get rid of prepntfs & add ntfs scanning to the Refresh Xml feature but this is only a small & limited part of the job to be done in wMM.
The wMM file manager will be in a very similar situation to MGZ file manager when it comes to dealing with fat32/ntfs..

 

[freddy38510]

I know about the error values, what I meant was that the values I gave were the originals (psl1ght) but didn't matter anymore. What I expected you to use were the ps3sdk values - 14 & - 15 so I was wondering why you didn't define those values directly....
What was the point in defining them as other errors instead? Sorry I could not look at sys/errno.h as I am not at home tonight...
To me, #define EOPNOTSUP ENOTSUP sounds good because it is exactly the same error but #define EADDRNOTAVAIL EAGAIN when cellsdk actually uses a EADDRNOTAVAIL in errno.h makes me pause... ?
Or maybe I missed something yesterday when I looked and EAGAIN uses the same value as EADDRNOTAVAI, as I said I can't check right now because I don't have the sdk with me.. If I have missed something then please forgive my babbling ok..? Lol

It's okay, we are here to make this library works the right way
EADDRNOTAVAIL and EADDRINUSE (and many others) are not defined by default in cellsdk. There are some conditions

#ifdef __PME__

If we defined "__PME__" we loose the lv2 error codes.

#if !defined(__PME__)
/* The Lv-2 error codes. */
#include <sys/return_code.h>
#endif

#ifdef __PME__
#define errno (_CSTD _Errno) // for special vsh
#else
int *_Geterrno(void); // for special vsh
#define errno (*_CSTD _Geterrno()) // for special vsh
#endif

So to avoid some issues later i prefered to replace EADDRNOTAVAIL and EADDRINUSE with more or less equivalents errors. Maybe i'm wrong and there is a better approach to that.

Before looking into integration strategies, the library functions need to be tested thoroughly though. I am hoping to do this tonight, I already have everything setup for it, I just need a few hours free time for debugging...

You're right, but i was affraid that we can't go further with the library. It seems that we've got some strategies like you said, so i'm relieved now

 

[freddy38510]

you didn't understand. It was convenient for me to use standart function but we can do without it, like it's done in iris for example...

for example if i open a file I can do this for NTFS and FAT32 :

f=fopen(file_path, "rb");​

But if i don't use standart function I have to "detect" if i'm in NTFS or FAT32 :

if( strstr(file_path, "ntfs") ) {

f = ps3ntfs_fopen(file_path, O_RD, 0777);​

} else {

f = sysFsOpen(file_path, ORD, 0777);​

}​

Understood ? anyway, webMAN MOD don't need it, trust me.

Tell me if i'm wrong, but it seems that ps3ntfs_open() function can works with FAT32 too like Estwald wrote it in "README_PS3.txt"

Also i have implemented in this functions support for PS3 internal devices as "/dev_hdd", "/dev_usb000" using
LV2 syscalls

// NTFS operation to write

int fd = ps3ntfs_open("ntfs0:/text.txt", O_CREAT | O_WRONLY | O_TRUNC, 0777);

if(fd < 0) error(fd);

-------------------

// FAT operation  to write (from internal device)

int fd = ps3ntfs_open("/dev_usb000/text.txt", O_CREAT | O_WRONLY | O_TRUNC, 0777);

if(fd < 0) error(fd);

 

[bguerville]

According to the Readme, you are right, the ps3 internal devices, like /dev_hdd0 or /dev_usbxxx are supported via use of lv2 syscalls.
ps3ntfs_chdir()
ps3ntfs_statvfs()
ps3ntfs_dirreset()
are the only exceptions due either to the nature of the function or because they only use absolute paths...

However there must a be a reason why other people do not use it though.. When you look at the Irisman source, more precisely file_manager.c, you get stuff like this:

if(is_ntfs) {            //if ntfs! 
ret = ps3ntfs_stat(path, &st); 
if (ret < 0) return ret;
ret = 0; 
(*size)+= st.st_size; 
}
else {                              //if not ntfs! 
sysFSStat stat;
ret = sysLv2FsStat(path, &stat); 
if (ret < 0) return ret;  
(*size)+= stat.st_size;
}

It's okay, we are here to make this library works the right way
EADDRNOTAVAIL and EADDRINUSE (and many others) are not defined by default in cellsdk. There are some conditions

#ifdef __PME__

If we defined "__PME__" we loose the lv2 error codes.

#if !defined(__PME__)
/* The Lv-2 error codes. */
#include <sys/return_code.h>
#endif

#ifdef __PME__
#define errno (_CSTD _Errno) // for special vsh
#else
int *_Geterrno(void); // for special vsh
#define errno (*_CSTD _Geterrno()) // for special vsh
#endif

So to avoid some issues later i prefered to replace EADDRNOTAVAIL and EADDRINUSE with more or less equivalents errors. Maybe i'm wrong and there is a better approach to that.

Ok. Now I understand & it makes sense..
I will look at it again tonight.. [emoji6]

 

[freddy38510]

According to the Readme, you are right, the ps3 internal devices, like /dev_hdd0 or /dev_usbxxx are supported via use of lv2 syscalls.
ps3ntfs_chdir()
ps3ntfs_statvfs()
ps3ntfs_dirreset()
are the only exceptions due either to the nature of the function or because they only use absolute paths...[emoji6]

It seems that Andoma commented out the portions of code that implement the support of internal devices via use of lv2 syscalls.
Like you can see here : https://github.com/andoma/libntfs_e...bcb#diff-7f9a0759ad07727e74826eec7361db8fR754

That explains why it didn't works when i tried it a few days ago.

 

[bguerville]

It seems that Andoma commented out the portions of code that implement the support of internal devices via use of lv2 syscalls.
Like you can see here : https://github.com/andoma/libntfs_e...bcb#diff-7f9a0759ad07727e74826eec7361db8fR754

That explains why it didn't works when i tried it a few days ago.

There must be problems with the feature because I cannot find a single brew that uses the library with /dev_hdd0 or fat32 devices....

 

[freddy38510]

There must be problems with the feature because I cannot find a single brew that uses the library with /dev_hdd0 or fat32 devices....

I have an other question for standard I/O.

If we call NTFS_init_system_io(), standard libc I/O functions are mapped to ps3ntfs_open(), etc...

So if we call fopen() in this context, could this function (and the others) works with internal ps3 devices? I'm not sure because the feature we were talking about has been removed.

 

[Zar]

yeah we can use ps3ntfs_open for both too. It's up to the dev.

I think if we use NTFS_init_system_io standart function are mapped and everything else is still working

 

[freddy38510]

yeah we can use ps3ntfs_open for both too. It's up to the dev.

I think if we use NTFS_init_system_io standart function are mapped and everything else is still working

But i merged the commits of Andoma, so actually ps3ntfs_open and others functions will not working with internal devices.

My assumption is that it would be the same for standard I/O functions. Because for example fopen() calls s_ps3ntfs_open() which calls ps3ntfs_open()

 

[bguerville]

I have an other question for standard I/O.

If we call NTFS_init_system_io(), standard libc I/O functions are mapped to ps3ntfs_open(), etc...

So if we call fopen() in this context, could this function (and the others) works with internal ps3 devices? I'm not sure because the feature we were talking about has been removed.

Has the feature been removed or changed in storage.h?
To me it looks like the lv2 syscalls code was changed but not removed. Am I wrong?

For example this part was removed:

lv2syscall2(609, device, (uint64_t) device_info);
return_to_user_prog(int);

And this was added instead:

return Lv2Syscall2(609, device, (uint64_t) device_info);

 

[freddy38510]

Has the feature been removed or changed in storage.h?
To me it looks like the lv2 syscalls code was changed but not removed. Am I wrong?

For example this part was removed:

lv2syscall2(609, device, (uint64_t) device_info);
return_to_user_prog(int);

And this was added instead:

return Lv2Syscall2(609, device, (uint64_t) device_info);

I talked about ps3_io.c. You can see some

#if 0

 

[aldostools]

However there must a be a reason why other people do not use it though.. When you look at the Irisman source, more precisely file_manager.c, you get stuff like this:

As you know, IRISMAN is based on Iris Manager... and for some reason (that I don't know) Estwald used libntfs functions only when ntfs is needed; but libntfs functions can be used to access files on internal HDD, fat32 or ntfs.

 

[bguerville]

As you know, IRISMAN is based on Iris Manager... and for some reason (that I don't know) Estwald used libntfs functions only when ntfs is needed; but libntfs functions can be used to access files on internal HDD, fat32 or ntfs.

But that is exactly what bothers me...
Estwald was the one who ported libntfs_ext, he implemented internal device support but then decided not to use it in his own Irisman?
In theory, using libntfs_ext for everything seems like a simpler option yet he would have chosen to complicate matters?
It really makes me wonder why..

 

[bguerville]

I talked about ps3_io.c. You can see some

#if 0

Oh.. I missed those #if 0 statements that are equivalent to commenting....

Have you tried to recompile after removing those statements to see if internal device support is working correctly again?

 

[freddy38510]

But that is exactly what bothers me...
Estwald was the one who ported libntfs_ext, he implemented internal device support but then decided not to use it in his own Irisman?
In theory, using libntfs_ext for everything seems like a simpler option yet he would have chosen to complicate matters?
It really makes me wonder why..

That's strange indeed. I compared date of commits between libntfs_ext and irismanager when ntfs was added, and i didn't find anything revelant.

Nevermind,

Have you tried to recompile after removing those statements to see if internal device support is working correctly again?

Not yet, but i will.

Edit: @bguerville i tried to uncomment only for function ps3ntfs_open() and it worked.

Edit2: I re-added support for ps3 internal devices. Look at this commit https://github.com/freddy38510/libntfs_ext/commit/e91a33ae1b290e94b3fe6349e82bbe34ca2621ff
The only function i tested for internal devices support is ps3ntfs_open, which is working (tested ntfs0, dev_hdd0, dev_usb000).

Edit3: I tested the returned errors values. It's working great.
Here is some log:

Writing to wrong path in usb000 : -2147418106
Writing to wrong path in ntfs0 : -1

From <sys/return_code.h> :

/** The file does not exist. */
#define ENOENT        -2147418106    /* 0x80010006 */

 

[bguerville]

Perfect @freddy38510

Sorry guys for the delay. Had trouble with my console not wanting to reset into Debug mode for some reasons, driving me nuts.
Joonie & I wasted many hours on solving this but finally I got it working.
I can begin testing. Will report.

 

[deank]

As you know, IRISMAN is based on Iris Manager... and for some reason (that I don't know) Estwald used libntfs functions only when ntfs is needed; but libntfs functions can be used to access files on internal HDD, fat32 or ntfs.

But that is exactly what bothers me...
Estwald was the one who ported libntfs_ext, he implemented internal device support but then decided not to use it in his own Irisman?
In theory, using libntfs_ext for everything seems like a simpler option yet he would have chosen to complicate matters?
It really makes me wonder why..

Actually these ntfs functions cannot fully replace cellFs functions when used for async I/O (which is used for faster copying of data). Also if libntfs_ext is to be used in a module (prx) it is best not to have redundant functions (because cellFs functions are already loaded by the prx). It decreases the size of the library and the size of the resulting prx. For game-apps (like Iris/Irisman) it won't matter at all, but for prx it makes some difference.

Also rewriting the whole app to use the new functions is tedious. For example I'm not sure if I'll do that with multiMAN, because it will probably take few weeks to add ntfs support.

 

[bguerville]

Actually these ntfs functions cannot fully replace cellFs functions when used for async I/O (which is used for faster copying of data). Also if libntfs_ext is to be used in a module (prx) it is best not to have redundant functions (because cellFs functions are already loaded by the prx). It decreases the size of the library and the size of the resulting prx. For game-apps (like Iris/Irisman) it won't matter at all, but for prx it makes some difference.

Also rewriting the whole app to use the new functions is tedious. For example I'm not sure if I'll do that with multiMAN, because it will probably take few weeks to add ntfs support.

Ok it make perfect sense now. There had to be a good reason for Estwald's choices. And as I suspected at the beginning, those functions are not really full replacements for Cellfs.
Substituting currently used functions with those is not as straightforward as we had hoped.
Thanks. @deank for these clarifications. It's really appreciated.

If you don't mind, could you enlighten me as well about the reentrant syscalls implementation used in psl1ght, what is the equivalent of this in cellsdk? For the moment we simply included the few related psl1ght sdk files directly into the project but surely something equivalent must already exist...