Author Topic: utMakeDirectory, can not make sub folder  (Read 7293 times)

Offline svl

  • Jr. Member
  • **
  • Posts: 52
    • View Profile
utMakeDirectory, can not make sub folder
« on: October 07, 2013, 01:44:33 PM »
Hi Mark

I am facing a few problems with the utMakeDirectory function.
From what I understand it should be possible to make a folder with in another folder just by doing like this:dir1/dir1?
But when use this code:

         if (ptr_utDirectory2 == 0) {
            ptr_utDirectory2 = utAllocateDirectory(DISK_D, 100); // allocate a directory for use by this module associated with D: and reserve its path name string length
            res = utOpenDirectory(0, ptr_utDirectory2);
         }      
         res=utMakeDirectory((int8*)"public", ptr_utDirectory2);
         res=utMakeDirectory((int8*)"public/steen", ptr_utDirectory2);
         res=utMakeDirectory((int8*)"public/steen/anette", ptr_utDirectory2);


I get a folder public and steen created in the root of my SD card and the folder anette is not created, the utMakeDirectory returns UTFAT_PATH_NOT_FOUND.

What am I doing wrong?
Further more I notes that LNF is not supported when creating folder, is this possible in any way.
I am looking forward to hear from you.

Regards
Steen



 

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: utMakeDirectory, can not make sub folder
« Reply #1 on: October 07, 2013, 02:57:04 PM »
Hi Steen

When I test your code I get the directory "anette" created, therefore I don't see any problem with the code itself.

Could you step through the routines involved with the line that should create the directory to see where the create actually fails? I am wondering whether the problem may be compiler dependent or timing specific in some way (?)

Although there are some defines prepared for creating long file names the present version doesn't allow writing LFN (neither file nor directory). This was originally to avoid any patent issues (the use of LFN requires licensing from Microsoft) but the Linux workaround is foreseen:

#define UTFAT_LFN_DELETE // support deleting files with long file names (cleaning up all LFN directory entries)
#define UTFAT_LFN_WRITE // support writing long file names
#define UTFAT_LFN_WRITE_PATCH // patch long file writes to potentially avoid patent issues


LFN delete is supported but the others not at the moment.

Regards

Mark


Offline svl

  • Jr. Member
  • **
  • Posts: 52
    • View Profile
Re: utMakeDirectory, can not make sub folder
« Reply #2 on: October 08, 2013, 09:49:32 AM »
Hi Mark

I have looked at the problem with creating the folders and this is what I found sofare.
I am using Keil uVision 4.71.2.0.

When doing like this:
         res=utMakeDirectory((int8*)"public", ptr_utDirectory);
         res=utMakeDirectory((int8*)"public/steen", ptr_utDirectory);
         res=utMakeDirectory((int8*)"public/steen/anette", ptr_utDirectory);
         res=utMakeDirectory((int8*)"public/peter", ptr_utDirectory);
         res=utMakeDirectory((int8*)"public/hans", ptr_utDirectory);

I get a folder struct on the SD card looking like this:
-public
-steen

When using this code:
         res=utMakeDirectory((int8*)"public", ptr_utDirectory);
         utChangeDirectory("public", ptr_utDirectory);
         res=utMakeDirectory((int8*)"steen", ptr_utDirectory);
         utChangeDirectory("steen", ptr_utDirectory);
         res=utMakeDirectory((int8*)"anette", ptr_utDirectory);

I get this struct on the SD card:
-public
  |-steen
     |-anette

I have been trying to debug the utMakeDirectory but are not able to locate the problem.
Hope this info can get us a bit closer to my problem?

Regards

Steen


« Last Edit: October 08, 2013, 10:27:20 AM by svl »

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: utMakeDirectory, can not make sub folder
« Reply #3 on: October 11, 2013, 10:10:20 PM »
Hi Steen

Is we discussed earlier today on the telephone I managed to reproduce these problems. For the sake of anyone reading this who have similar difficulties I have put the explanation and "workaround" below.

From utFAT1.14 I will change the operation slightly so that when the 'virtual' directory is opened/set it will automatically set the flag and so automatically 'lock' the location. This will ensure that such strange behaviour doesn't result, without the need for this location to be locked in the user's code.

Quote
It is the lack of the flag UTDIR_REFERENCED that is making the difference. The reason for this flag is to allow a user to open a directory on the card for use as a ‘virtual’ root directory – this is performed when utOpenDirectory() is called without this flag being set on (which is always the case when starting with a new directory object). When the open is made like this the directory object’s “private’ pointer is set to this “virtual” root location so that following accesses are relative to it. An example of its use is when working with the web server where its working area (virtual root) is defined by UTFAT_HTTP_SERVER (eg. “http_dir”). The first open therefore sets its working root and then all further operations are referenced to it (it is not possible to move up any further than this location so the virtual root restricts the area on the disk that can be accessed). Each application can therefore have its own root if required (you are opening the root directory as your virtual root and so you can access the complete disk).

In the case of the FTP server and HTTP server the flag is set after the root has been successfully set.
In the case of the command line interface it is not set after the root has been set BUT it IS set as soon as a directory listing is performed.

In your case it is not set and so any additional use of the open (the open is used for making files and directories – also if they fail as in one problem case) will cause the “virtual” root to be ‘moved’.

Setting
ptr_utDirectory->usDirectoryFlags |= UTDIR_REFERENCED;
after opening the working directory will work-around it.

Regards

Mark