#132601 - psychowood - Thu Jun 28, 2007 3:29 am
Hi,
isn't out there a working function to move a directory? I'm trying with the POSIX rename but it doesn't work (neither for a dir nor for a single file)...
Am I missing something? Please don't tell me I have to open-read-write-close every file... :|
TIA
#132603 - DragonMinded - Thu Jun 28, 2007 3:33 am
It's the rename function, but I think it works on files individually.
_________________
Enter the mind of the dragon.
http://dragonminded.blogspot.com
Seriously guys, how hard is it to simply TRY something yourself?
#132630 - psychowood - Thu Jun 28, 2007 9:39 am
| DragonMinded wrote: |
| It's the rename function, but I think it works on files individually. |
I did try for a single file (to move 'rename("/DIR/filename.ext","/filename.ext")' or to rename 'rename("/DIR/filename.ext","/DIR/filenameB.ext")' ) but doesn't work either, both on No$GBA with FCSR and on a real cart (EZ4 with the correct dldi driver).
#132637 - spinal_cord - Thu Jun 28, 2007 10:13 am
Would you not have to COPY then file to the new location, then delete the original? Thats how I would tackle it.
_________________
I'm not a boring person, it's just that boring things keep happening to me.
Homepage
#132640 - psychowood - Thu Jun 28, 2007 10:21 am
| spinal_cord wrote: |
| Would you not have to COPY then file to the new location, then delete the original? Thats how I would tackle it. |
Yep, that's what I'm going to do now, but I thought that using a known working function would've been safer, and a lot quicker, too.
#132641 - kusma - Thu Jun 28, 2007 10:33 am
doesn't the copy/delete approach require twice the amount of disk-space for the file?
#132643 - psychowood - Thu Jun 28, 2007 10:39 am
| kusma wrote: |
| doesn't the copy/delete approach require twice the amount of disk-space for the file? |
Yes but, at least in this specific case, it isn't a problem, because it will be used to move many small files (savers).
#132660 - spinal_cord - Thu Jun 28, 2007 1:54 pm
Are we going to see a DS explorer any time soon, or are these just tests?
_________________
I'm not a boring person, it's just that boring things keep happening to me.
Homepage
#132668 - psychowood - Thu Jun 28, 2007 2:41 pm
| spinal_cord wrote: |
| Are we going to see a DS explorer any time soon, or are these just tests? |
Not made by me, at least not anytime soon, sorry.
I'm just doing a tool to help EZIV users to go around the 80 files limit of that flashcard.
#132735 - tepples - Fri Jun 29, 2007 12:49 am
I'd make a file manager for the DS myself in order to get away from the gba_nds_fat bugs that are still in the popular one, but it appears that unless you have two adapters one in each slot, it's just not practical to copy files from one card to another.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#132739 - spinal_cord - Fri Jun 29, 2007 1:15 am
I like the idea of copying between two cards, I have R4 and GBAMP, the larger card being in my GBAMP. I'd like to be able to use my DS to copy files frem the microsd card in the R4 to the GBAMP, so I can use the microsd in peoples phones, and copy mp3 ringtones and I'm starting to sound a little childish, but it IS a good idea.
_________________
I'm not a boring person, it's just that boring things keep happening to me.
Homepage
#132814 - cory1492 - Fri Jun 29, 2007 8:39 pm
To quote myself... when attempting to use
| Code: |
| rename(const char *old, const char *new) |
which should work on both files and direcotries if implemented right (and as far as I can tell the code is there so it should be working), after the call, errno is 134 (ENOTSUP /* Not supported */); the only function I am seeing that error returned from in libfat is "_FAT_link_r" which is not called by the rename function (_FAT_rename_r).
Maybe I'm missing something else?
#132842 - kusma - Sat Jun 30, 2007 2:09 am
| cory1492 wrote: |
To quote myself... when attempting to use
| Code: | | rename(const char *old, const char *new) |
which should work on both files and direcotries if implemented right (and as far as I can tell the code is there so it should be working), after the call, errno is 134 (ENOTSUP /* Not supported */); the only function I am seeing that error returned from in libfat is "_FAT_link_r" which is not called by the rename function (_FAT_rename_r).
Maybe I'm missing something else? |
According to http://devkitpro.cvs.sourceforge.net/devkitpro/libfat/source/fatdir.c?revision=1.7&view=markup libfat shouldn't call _FAT_link_r, and _FAT_rename_r doesn't return ENOTSUP(as you're saying). This leads me to the conclusion that you're using an out-of-date libfat. If you aren't, add tracing to the source-code of libfat, or step through it in a debugger to see what's really going on.
#132845 - cory1492 - Sat Jun 30, 2007 3:33 am
Could whatever accessors devoptab(sp?) provides be the source of the not supported result? I know my toolchain is dated (R20) compared to libfat (c/o and compiled on april 22), but I have never taken time to go digging through it's source to see how libfat is wired into it "under the hood".
For that matter, anyone have rename(,) working right this second at all (R20, recent libfat)? I'll keep digging if I know it's just the two of us with problems (though it isn't something I really need at this point).
#132853 - psychowood - Sat Jun 30, 2007 10:16 am
| cory1492 wrote: |
| For that matter, anyone have rename(,) working right this second at all (R20, recent libfat)? I'll keep digging if I know it's just the two of us with problems (though it isn't something I really need at this point). |
FYI, I just recompiled libfat from source (is libfat-20070127 the latest one?) and I can confirm that rename(,) still throws an errno 134 (FCSR, EZ4Dlx and DSLink).
Edit: Same results using latest CVS.
#132866 - cory1492 - Sat Jun 30, 2007 7:12 pm
With this change in fatdir.c:
| Code: |
int _FAT_rename_r (struct _reent *r, const char *oldName, const char *newName) {
PARTITION* partition = NULL;
DIR_ENTRY oldDirEntry;
DIR_ENTRY newDirEntry;
const char *pathEnd;
u32 dirCluster;
return -2;
... |
I still get -1/err 134 returned from rename(); it appears notsup/error is returned before the rename function even gets called...
#132887 - chishm - Sun Jul 01, 2007 3:09 am
This might be a problem with the newlib rename stub calling the wrong function (link/unlink instead of rename). We will work on fixing this.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com
#132888 - MrD - Sun Jul 01, 2007 3:53 am
| Quote: |
| We will work on fixing this. |
You don't half sound like the King of All Cosmos... :)
_________________
Not active on this forum. For Lemmings DS help see its website.
#133031 - kusma - Mon Jul 02, 2007 8:40 pm
| chishm wrote: |
| This might be a problem with the newlib rename stub calling the wrong function (link/unlink instead of rename). We will work on fixing this. |
Could it be that it does so (link/unlink instead of rename) if the link-function is non-null?
#133075 - wintermute - Tue Jul 03, 2007 3:38 am
Confirmed bug in my newlib stdio hackery. I have it fixed in my current devkitARM release 21 WiP, to be released "real soon now"?
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#133076 - chishm - Tue Jul 03, 2007 3:43 am
#133104 - psychowood - Tue Jul 03, 2007 8:52 am
Nice, seems that, after all, it wasn't my fault ^^
#133299 - cory1492 - Thu Jul 05, 2007 3:32 am
| psychowood wrote: |
| Nice, seems that, after all, it wasn't my fault ^^ |
Nope, it was just your fault it will be fixed in some "probability factored future"(??).
Thanks wintermute.