Yes, it would, but it would be very worthwhile work, because once we make such a switch it will solve not only the immediate problems, but also ease future implementations. And that's not just for LaunchELF. The improved drivers needed for this can be used by other software too.
Writing one version after another, over and over, of what is basically the same functions but modified for each device, that is also hard work, and NOT really worthwhile. I say that because each time we do such work, it solves only the immediate problem. Next time we want to do something similar again we still have to do it all over.
True. Like all powerful system tools, it has some unusual needs.
LaunchELF's current implementation doesn't quite fit the mold.
Well, neither can I. Still, as I see it we should be able to use fioGetstat + fioChstat, or fileXioGetStat + FileXioChStat, to both read and modify basic file attributes and file date_time fields. But like I said, the current drivers don't have this properly implemented.
I'm still don't follow all the ways of doing system/driver calls for stats unfortunately.
The best one is the MC driver, not surprisingly, as we still use the IRX internal to the console, so it was designed by Sony. The bad side of this is that we can't modify it (well I can, but I won't !!!), as that would then be illegal to distribute. But the good side is that it tells us what Sony regards as normal for these functions, so we can add similar functionality to homebrew drivers.
Here are some current results from my testing:
fio_stat_t structure elements for MC, delivered by fioGetstat:
mode = 0x17 for file, 0x27 for normal folder, 0x2F for protected save folder
That protection bit did not exist for the files, who all had 0x17.
Note also that the 'preserved'/CLOSED bit is not present here, so that still requires device specific access methods.
mode = 0x1027 is returned for PS1 save folders on a PS2 MC, when copied to the PS2 by the official PS2 browser, but the file inside such a folder still has 'mode = 0x17'. I have seen no file on PS2 MC with different mode value.
mode = 0x1F is returned for all save files on a PS1 MC, but the differing bit does not have the same meaning there, as those saves are NOT protected.
attr = Zero, at all times tested. (Sad, but true.)
size = file size, but zero for folders
ctime = create time in 8-byte struct identical to substruct '_create' in mcTable
atime = similar struct, but zeroed.
mtime = similar struct, holding modification time.
Edit: On PS1 MC some of my files have valid ctime and mtime fields, while some just have zeroes. I believe this to be the result of different copying methods. My games don't seem to care, but since the PS1 never had a proper real-time clock, I believe that the zeroes are the original standard. But it's interesting to note that the PS1 file format apparently supports time fields anyway. Possibly the original PS1 plans did include a clock, though it was left out to cut production costs.
I have not yet tested fioChstat effects, but if these too are similarily implemented for MC, then we are all set for adding the same functionality to the other drivers.
You may have misunderstood me. Each time when I say 'time' in this context, I actually mean a struct containing both date and time. For USB these structs were all completely zeroed in each fioGetstat call. Not just 'atime', and not just the 'time-of-day' fields, but all of them were entirely zeroed. The same also applies to HOST, CD, and HDD (using fileXioGetStat).
Yeah no time but it has last accessed month, day, and year from what I remember from before. I got zeros with time too. USB devices don't support time, hh:mm:ss, for last accessed even under windows.
As for 'last access time', I have always been opposed to its implementation, since way back in time, when this abysmally bad idea first appeared. I never could understand how even half-way decent software engineers could even consider adding a set of directory write accesses for each file access. Remember that in a perfect implementation the driver needs to 'touch' the 'atime' field for each new read/write call, not just when the file is opened or closed. Think of the speed loss this will inevitably cause. (esp. when streaming...)
IMHO, the entire concept is insane.
So, putting it differently:
I do not exactly mourn the lack of 'atime' support in our drivers... ;)
I just had a look at that stuff (never really studied it before).
That's what I was thinking before. Ps2ftpd uses FileSystem_ReadDir which uses the dread command to read in data from a device then it can use getStat later to retrieve the info.
At first look it seems a bit cryptic, like in:
"pContext->m_kFile.device->ops->getstat(" and so on, but it does seem to use a function pointer from a device specific function table, and surely we can do something similar. But it remains an open question what those functions will return if we use them...
Also, we have to remember that 'ps2ftpd' executes in IOP space, whereas the main LaunchELF code executes in EE space, so whatever we do, our methods will have to differ somewhat. Just calling those functions directly is not on.
Yes, I know. I had the same need for my testing, so I made some changes to 'filer.c', to allow stat info to be displayed when using the submenu command "Get Size". The extra display only appears when using it for a single object (either marked or selected). The 'mode' and 'mtime' fields are shown on the same screen line as the size, but with ps2client or InLink you can see the entire fio_stat_t struct (or the matching portion of an iox_stat_t struct for HDD).
The ftp stuff I worked on gave me quite a bit of insight on attributes. I'm still almost clueless when it comes to handling them in LaunchELF itself. I had wanted to put something together that would allow me to see then from within LaunchELF. As you're aware there isn't a real nice clean way to do that.
I'm attaching this modified 'filer.c' so you can play around with it too.
Of course it will.
OK. I still think that mcPaste would still be take quite a lot of work though.
When I said 'Immediate implementation' I simply meant that I am ready to start immediately. Only time can tell when it will be finished.
The only thing holding me back slightly now is that I'm feeling a strong urge to fix those drivers too... Giving them a minimal fioGetstat support, similar to MC, should not be all that hard. But of course, I have to experiment with fioChstat too.
That is the real bloat-killer for cases where an application modifies dates, and that's something LaunchELF needs for ALL cases of copying, since both 'ctime' and 'mtime' fields should be preserved when a file is copied without changes.
(I know some disagree about 'ctime', but that is how I see it.)
Best regards: dlanor