VxWorks / Tornado II FAQ

3. File System problems

3.1 Dos file system

3.2 Flash File system

3.3 Floppy-disk File system

3.4 RAM-disk File system

3.5 General file system questions

Index

Q: All my files on the disk have the date 1 Jan 1980. How can I get the system to use the actual date?

A: This is a problem related to the original DOS-FS implementation. With the introduction of the new implementation, DosFS2, this problem has disapeared. There are also a lot of other changes and improvements made to the DosFS system. It is advisable to use this version instead of the original. DosFS2 is a free update to Tornado-2 and can be obtained from your local sales representative.

Within the old DOS file system the current date is not used. You have to use a hook to do this. See the following code to create a funtion that changes the file-time to the actual time:

void
dosFsDateTimeHook(DOS_DATE_TIME *pDateTime)
{
    time_t              tm_t;
    struct tm           currTime;
    struct timespec     timeSpec;

    tm_t = time(NULL);
    localtime_r(&tm_t, &currTime);

    /* pass values to DOS date and time structure */

    pDateTime->dosdt_year = currTime.tm_year+1900;
    pDateTime->dosdt_month = currTime.tm_mon + 1;
    pDateTime->dosdt_day = currTime.tm_mday;
    pDateTime->dosdt_hour = currTime.tm_hour;
    pDateTime->dosdt_minute = currTime.tm_min;
    pDateTime->dosdt_second = currTime.tm_sec;
    }
    

Then add the following line to your startup code (for example after the initialization of dosFs).

dosFsDateTimeInstall(dosFsDateTimeHook);
    

See also the description of dosFsLib in the VxWorks Reference Manual.

Q: When I create a file with a size of 0 on a removable medium with VxWorks and run Scandisk on a PC on this filesystem, Scandisk complains about Incorrect file size. This in only the case if the size is 0.

A: This has been a known problem with dosFsLib for a few years, and it is fixed in DosFs 2.0. Here are some more details:

• The NFS server module uses the number of the first cluster of a file (16 bits) as part of its File Handle, together with a running generation counter. Because of this requirement of NFS, dosFs was modified (between VxWorks 5.1.1 and 5.2) to allways allocate at least one cluster to a file, even if it was completely empty, with 0 bytes.
• This is not entirely in-line with Microsoft implementations which do not allocate clusters to empty files, and leave the first cluster number in directory entries as 0 for file with no data.
• The action taken by ScanDisk is based on the assumption that since the file has one cluster allocated to it, the system went down before it had a chanse to update the file size field in the directory entry, and adjusts this field in an attempt to salvage possibly lost data contained in that allocated cluster.
• Hence it is clear that even though this slight incompatibility issue was known for some time, (in addition to other small issues) it could not be "fixed" without redesigning the NFS server module to use other means to generate File Handles.

With DosFs 2.0, the file system as well as the NFS server where redesigned in a way that does away with all the compatibility issues, and making FosFs 2.0 and NFS server completely isolated one from the other.
(From: Leonid Rosenboim, leonid@bitband.com)

Q: With the new disk partition manageger which is part of the dosFs2.0 release, is there an elegant means to mount all the valid partitions ?? Since the current code does not actually do the mount until the first access, none of the calls (dpartPartGet() and dosFsDevCreate() for example.) return errors even if the partition you are mounting really doesn't exist. You have to access it first.

A: DosFs 2.0 requires you to specify the maximum number of partition you EXPECT to see on the disk, and to provide each of these expected partition a logical device name. Sinc VxWorks does not have (never had) an automatic mechanism for assigning logical names to devices (a'la A:, B:, C:, ... in MessDos), and a logical name is a necesity to be able to access the device after initialization.
Alternatively, the number of expected partitions can be large, since it is not an error if there are less partitions on the actual disk then expected - the exraneous partitions will have logical device names associated with them, but will yield an error on any access attempt. Moreover, the number of expected partitions must accomodate any removable disk which could be inserted into a particular drive.
The partition mamager module "dpartCbio" has an arbitrary limitation of 8 partitions, that is supposed to be sufficient for most applications. Many operating systems have a similar limitation (SunOS, Solaris have max 8 partitions per disk drive) which are seldom reached.
It could be possible by slight modification of dpartCbio source code to get more partitions, but my feeling is that there is something strange if you need more then 8 partitions on a disk, perhaps your design considerations should be revised...
(From: Leonid Rosenboim, leonid@bitband.com)

Q: Is it possible to use FTP with the raw file system?

A: The ftp server uses open/read/write/close the same as any other program, so can read (and write) raw filesystems.
You will need to use a 'proper' ftp client to request the required transfer. None of the windows 'file manager' style ftp clients interact well with the vxWorks ftp server.
If you create a raw file system covering the same disc space as a dosfs one, you can take an image of the current state of the filesystem and restore it at a later date. (Assuming no files are open ...)
One thing I found is that the ftp server requires that the raw device driver error reads for zero bytes at the end of file - otherwise the ftp doesn't complete.
(From: David Laight, dsl@tadpole.co.uk)

Q: When I create a direcory chkdsk complains at the next reboot.

A: Seems you are rebooting too soon after creating the directory, it had the chance to update the FAT but not the root (parent) directory, so there is a cluster allocated which is not referred from any directory entry, thus it would reclaim it in an attempt to salvage potentially lost data.
If you do some more operations prior to rebooting, it will be able to flush the buffers and then all will be consistent.
With TFFS, disk write operations are rather lenghy, perhaps you shold try the same with a RAM disk or some other media with the same DosFs setup.
(From: Leonid Rosenboim, leonid@bitband.com)

Q: Why does the task 'dCacheUpd' take so much of the processortime?

A: You have correctly identified the task responsable for using-up your CPU.
Knowing Flash, my guess is that what you see is the busy-loop delay code of the MTD used to wait for completion of every Flash memory write operation. Typical Flash memories require delays of 6 to 14 microseconds for each byte written, and busy-loop is a common solution for such timing requirement.
The reason this happens in Disk Cache task is that the write operations your application calls write to the disk cache, which using the write-back machnism updates that data to the disk at a later time.
As a first-off solution recommendation, I would recommend that you tune the Disk Cache task priority to be sufficiently low so as not to interfere with other functions of your application, this could potentially slow down the maximum write speed, depending on how much CPU time the disk cache task is eventually getting, and this can also somewhat increase the lag time between the write() call from your application, till its on the Flash.
There are other ideas which could cause the CPU time used to write Flash to be spend on behalf of the task which calls write() rather then the disk cache, decreasing the time-lag, but I am afraid this won't improve any other factor.
One good way to improve all aspects of this, is to use Compact Flash ATA cards insead of TrueFFS, which have on-board microcontroller doing all that greesy Flash timing for you without consuming any CPU time at all.
(From: Leonid Rosenboim, leonid@bitband.com)

Q: How can I unmount a DOS-filesystem?

A: Unfortunately 'unmount' isn't part of the dosfs spec. Even in dosfs2. Apparantly 'there is no requirement for it'
WRS Support will send you a load of 'unsopported code' that (if compiled with the correct header files etc) will completely free up all the data areas allocated by dosfs. However things will go 'tits up' if there are any open files, and more so if you cannot guarantee that a file isn't being opened (by another task) at the same time as you are freeing all the data areas!
(From: David Laight, David.Laight@btinternet.com)

Q: Why does a file, when deleted on the target, still appear on the NFS exported drive?

A: The client will compare directory names (cache against server) before it will assume the directory is unchanged and use cached handles, but dosFs 1.0 does not update directory modification time when a file is deleted,
In other words, dosFs 1.0 and its NFS server can offer no solution to this situation.
(From: Leonid Rosenboim)

Q: With DosFS2 some of our files started disappearing.

A: DosFs 2.0 has a problem with Tornado 2.x on PowerPC 603/604 architecture (or other derivatives using the 603/604 compule flag), which is due to PowerPC compiler improper code generation for 64-bit integer operations used throughout DosFs 2.0.

This bug could is tricky to catch, it will bite you only if you have some tasks doing Floating Point calculation, and task switch taking place between these and other tasks doing DosFs I/O in midst of 64-bit arithmetics. So do not be fooled to beleive you eint got it!

For those who got DosFs 2.0 source code, this can be solved by either compiling the library with -msoft-float compile flag, or by disabling 64-bit math (not recommended). For binary only licensees, you need a patch which is available from WINDSURF.

References:

SPR # 71089
Additional SPR # 33221,33702,33684,34704,62415,28428

(From: Leonid Rosenboim)

Q: What is the maximum number of files in a directory?

A: There's no limit to the number of files in sub-dirs (afaik) apart from the FS size limit. There is a limit for the root dir.
But the DOS FS is very inefficient when the number of entries in a directory becomes large.
Even when the files are deleted, access time to the directory to create new files remains slow - just as if the original files had not been deleted. (When files are deleted, they're just marked for deletion but their entry stays in the directory).
I could not find a nice solution to this - it's an inherent design problem with the DOS FS.
One work around is to delete the directory, re-create it then access times return to normal --- but that's only any good if you can delete the files.
(From: Chris Richards, cj_richards-remove-@hotmail.com)

Q: When my system boots from network the network link is opened , but when I use TFFS as a boot device the network is not opened.

A: Define the ethernet device in the "other" boot parameter, for example if the original boot device is cpm(0,0) the other (o) parameter should be cpm. The bootline in this case could be if you want to boot from a flash disk:

$tffs=0,0(0,0)host:vxworks e=<target IP> o=cpm
    

(Needed: Include Network components\basic network initialization components\bootline processing components\network device name selection)

If this does not help it probably means that the device you want to boot from is not defined in usrNetBoot.c In the function usrNetDevNameGet only the standard file devices (SCSI, IDE, ATA) are checked. If one of these is available the "other" boot parameter is checked, but if another device is used the parameter is not checked.
To fix this add the line with the '+' sign to the module target\config\comps\src\net\usrNetBoot.c (line 97):

  if ( (strncmp (sysBootParams.bootDev, "scsi", 4) == 0) ||
+      (strncmp (sysBootParams.bootDev, "tffs", 4) == 0) ||
       (strncmp (sysBootParams.bootDev, "ide" , 3) == 0) ||
       (strncmp (sysBootParams.bootDev, "ata" , 3) == 0) ||
       (strncmp (sysBootParams.bootDev, "fd" , 2) == 0))
    

When some other device is used replace tffs with the correct device name.

Q: Can I use long filenames with TFFS?

A: Assuming you are using the old dosFs, which is shipped with Tornado 2, then you are out of luck:
TrueFFS is very nosy about the DosFs structure stored on its volumes, and the only safe way to use it is to format a TrueFFS volume only with the format function supplied with TrueFFS. Never use dosFsMkfs() to format a TrueFFS volume.
DosFs long names are non-standard, and can be created only with dosFsMkfs(), and are known to cause file data to dissapear when used with TrueFFS, because TrueFFS's idea of the meaning of some fields in the boot block and DosFs's idea vary. This has been documented in the SPR database.
Your solution is to either go to DosFs 2 which supports standard VFAT long names, or to do away with TrueFFS.
(From: Leonid Rosenboim, leonid@bitband.com)

Q: I want to use TFFS with a Raw file system. Is this possible?

A: The MS-DOS specific code in TrueFFS could be disabled by calling the routine tffsDevOptionsSet() right after the call to tffsDevCreate().
Once you have done this, you should be able to use TrueFFS with raw filesystem.
(From: Andrey Kaganovsky, andreyk@home.com)

Q: Is there an alternative for TFFS?

A: There are several alternative flash filing systems. There is also one that is released under GPL, called JFFS (Journaling Flash File System). This can be found at: http://developer.axis.com/software/jffs/.
(From: Hwa Jin Bae, bae@mail.com)

Q: I have problems getting TFFS to work with StataFlash chips.

A: I had the same problem and found that the problem was a low-level flash interface problem (and there was no way to tell that from the tffsDevFormat() call results - this was confirmed by WRS tech "support".)

I had to debug at the sockets layer, to find out where the error(s) were. When I flushed out all the socket interface layer bugs, the tffsDevFormat() worked. Basically; get it to the point that you don't have any error messages from the socket layer, and it seems to work ok

There are a good many debug statements in the cfiscs.c file - I just turned them on, and added a few of my own, to track down the problem. I left the error (as opposed to debug info) messages enabled in cfiscs.c - this has turned out to be *very* helpful during development.

It would be very nice if any low-level (socket layer) problems were somehow passed up the to the higher layers, so that you could get a meaningful response from the API-layer calls. But, then, it has been my experience that, if an error occurs at a lower software layer, all bets are off (we have frequent vxWorks hang conditions due to this problem).

Our board has multiple flash chips, and I also found it helpful to be able to limit the number of flash chips used (because we had chip-location-specific hardware problems). I got it to work with a single chip, first (our chips are 4MB each).
(From: Bill Fulton, bill_a_fulton_please.nospam@raytheon.com)

Q: How can I defragment a TFFS volume?

A: To defragment TrueFFS flash array, you can use code fragment similar to the one below:

    #define HUGE_SECTORS 0x70000000  /* impossible number of sectors */

    int  freeSectors;  /* space for buffer. */

    (void) tffsRawio (0, TFFS_DEFRAGMENT_VOLUME, 
                       HUGE_SECTORS, (int)&freeSectors, 0);
    

The call above could return error code, but, as far as I know, it is safe to ignore it. If media is badly fragmented, the call above can take very long time to complete, since it is doing complete defragmentation of the entire flash array.
(From: Andray Kaganovsky, andreyk@home.com, and Bill Pringlemeir, pringle@sympatico.ca)

Q: How can I access a TFFS device using raw I/O after it was mounted?

A: Here is an umount and mount function that was suggested by our WindRiver FAE:

#include "tffs/fatlite.h"

/*************************************************************************** ****
*
* tffsUnmout - Unmount the requested drive
*
* This routine unmounts a TFFS drive.
*
* RETURNS: OK or ERROR
*/
STATUS tffsUnmount(int tffsDriveNo)
{ 
    IOreq ioreq; 
    FLStatus status;
    ioreq.irHandle = tffsDriveNo; 
    status = flCall(FL_DISMOUNT_VOLUME ,&ioreq); 
    return ((status == flOK) ? OK : ERROR); 
}

/*******************************************************************************
*
* tffsMount - Mount the requested drive
*
* This routine mounts a requested TFFS drive.
*
* RETURNS: OK or ERROR
*/
STATUS tffsMount(int tffsDriveNo) 
{ 
    IOreq ioreq; 
    FLStatus status;
    ioreq.irHandle = tffsDriveNo; 
    status = flCall(FL_MOUNT_VOLUME ,&ioreq); 
    return ((status == flOK) ? OK : ERROR); 
}
    

I modified tffsBootImagePut() to unmount the flash drive, re-write to the boot region, and re-mount the flash drive. tffRawio() and tffsBootImagePut() in conjunction with tffsMount() and tffsUnmount() are working very reliably now.
(From: M. Nurmohamed, mehmood@gte.NOSPAM.net)

Q: How can I format a 128 Mbyte device? I can only see 32 Mbyte.

A: AFAIK, your limit should not be 32MB, but 40MB. You'll find in target/h/tffs/flCustom.h:

#define MAX_VOLUME_MBYTES 40
    

I had to increase SECTOR_SIZE_BITS (512 byte->1024 byte) to get over 64MB. Change this defines and recompile TFFS-sources if available or ask your FAE.
(From: Michael Lawnick, Lawnick@softec.de)

It is true that TFFS limits size of the single TFFS volume to 40MBytes. If you happened to have TFFS source code, then Michael's suggestion above will allow you to work around this limit. If you don't have TFFS source code, then you can "partition" your physical flash array into independent TFFS volumes. You will have to do minor change in your TFFS's socket code in <bsp_dir>/sysTffs.c to do address wrap around 32MBytes offsets.
This will allow you to install four socket components, with base addresses as follows:

    socket #   address range

     0         <flash_address> ...        <flash_address> +  32MB
     1         <flash_address> + 32MB ... <flash_address> +  64MB
     2         <flash_address> + 64MB ... <flash_address> +  96MB
     3         <flash_address> + 96MB ... <flash_address> + 128MB
    

Each of the memory ranges above can be formatted and mounted as independent TFFS volume. Depending on the size of the physical flash parts that comprise your flash array, and flash array's interleaving, you can do I/O in parallel to all four TFFS volumes, which can greatly improve 'write' performance.
(From: Andray Kaganovsky, andraykNOSPAM@primus.ca)

Q: How can I reduce wear by updating the "Last Accessed" field?

A: The code changes are very easy, but you might have to ask your FAE to do this, as this source code is not included in the standard distribution.
"dosFs/dosFsLib.c" needs to be changed. I have a diff below. However, I think you just need to search for "->accessed" and note how the code is being used to understand. There are about three to four occurrences of this. As Leonid noted, this should probably be configurable.

[dosFsLib.c differences]
*** c:/TEMP/dosFsLib.c.~1.2~	Wed Feb 27 19:52:55 2002
--- c:/TEMP/dosFsLib.c.~1.1.~	Wed Feb 27 19:52:55 2002
***************
*** 2532,2543 ****
      	}
      
      /* update file's directory entry */
!     if(cbioModeGet(pVolDesc->pCbio) != O_RDONLY)
!     {
!         pFd->accessed = 0;
!         if(pFd->changed)
!             pVolDesc->pDirDesc->updateEntry(pFd, DH_TIME_MODIFY, time(NULL));
!     }
      /*
       * flush buffers and deallocate unused clusters beyond EOF,
       * if last file descriptor is being closed for the file
--- 2532,2547 ----
      	}
      
      /* update file's directory entry */
!     
!     if( cbioModeGet(pVolDesc->pCbio) != O_RDONLY &&
!         ( pFd->accessed || pFd->changed ) )
!     	{
!     	u_int	timeFlag = (pFd->accessed)? DH_TIME_ACCESS :
! 					    DH_TIME_MODIFY ;
!     	pVolDesc->pDirDesc->updateEntry( pFd, timeFlag, time( NULL ) );
!     	pFd->accessed = 0;
!     	}
!     	
      /*
       * flush buffers and deallocate unused clusters beyond EOF,
       * if last file descriptor is being closed for the file
***************
*** 3986,3996 ****
              retVal = OK;
              
              /* store directory entry */
!             if(pFd->changed)
!             {
      	    	retVal = pVolDesc->pDirDesc->updateEntry(
!     	    			pFd, DH_TIME_MODIFY, time(NULL));
!             }
              if( retVal == OK )	
              	{
      	    	retVal = cbioIoctl( 
--- 3990,4003 ----
              retVal = OK;
              
              /* store directory entry */
!             
!             if( pFd->accessed || pFd->changed )
!             	{
!     	    	ptrBuf = (void *)((pFd->accessed)? DH_TIME_ACCESS :
! 					           DH_TIME_MODIFY  ) ;
      	    	retVal = pVolDesc->pDirDesc->updateEntry(
!     	    			pFd, (u_int)ptrBuf, time( NULL ) );
!     	    	}
              if( retVal == OK )	
              	{
      	    	retVal = cbioIoctl( 
    

(From: Bill Pringlemeir, spam_account@sympatico.ca)

Q: Why do I get a "S_dosFsLib_FD_OBSOLETE" once in a while, when I keep a file open?

A: It turns out that some people who use TFFS find out that sector 0 changes from time to time (presumably by TFFS), which in turn is detected by Dcache as "disk change", and that in turns renders all currently open FD's as obsolete, and remounts the device.
Nobody has yet come up with a clear description about WHY does TFFS change values of the sector 0 (boot sector), or what sepcific values does it change, and there is no means as of yet to turn this activity off.
You can however do away with Dcache - TFFS has no moving parts and thus the performance benefit of using disk cache is minimal. Without disk cache, performance will not signigicantly change, and there will not be any detection of sector 0 changes, so you will not get the "FD Obsolete" error.
(From: Leonid Rosenboim, MY_FIRST_name@CONSULTANT.COM)

Q: After moving from T2.0 to T2.2 TFFS gives compilation errors on tlTable in tffsConfig.c.

A: I am informed by Wind River that including curly braces around the NULL cures this problem. There is an SPR on this but, as usual, they haven't published it yet.
Try {NULL} instead of NULL.
(From: Pat Barlow)

Q: I try to create a floppy device using usrFdConfig(0,0,"/fd0/") as suggested in the programmer's manual, but I always get the "dosFsDevInit() failed" error message. How can I avoid this message and have the system create the device?

A: Typically there is no floppy in the drive. We found a workaround that initializes the datastructures needed by the dosFsDevInit() call for a floppy with 3.5" and 1.44Mb.
Following is the change that should be made to usrFd.c to initialise this structure.

--- org\usrfd.c
+++ new\usrFd.c
@@ -54,6 +54,7 @@
     )
     {
     BLK_DEV *pBootDev;
+    DOS_VOL_CONFIG DVC;
     char bootDir [BOOT_FILE_LEN];
 
     if ((UINT)drive >= FD_MAX_DRIVES)
@@ -74,9 +75,20 @@
 
     devSplit (fileName, bootDir);
 
+    /* Modification: create the dosvolume data struture */
+    DVC.dosvc_mediaByte = 0xf0;  /* media descriptor byte */
+    DVC.dosvc_secPerClust = 1;  /* sectors per cluster (minimum 1) */
+    DVC.dosvc_nResrvd = 1;   /* number of reserved sectors (min 1) */
+    DVC.dosvc_nFats = 2;   /* number of FAT copies (minimum 1) */
+    DVC.dosvc_secPerFat = 9;  /* number of sectors per FAT copy */
+    DVC.dosvc_maxRootEnts = 224; /* max number of entries in root dir */
+    DVC.dosvc_nHidden = 0;   /* number of hidden sectors */
+    DVC.dosvc_options = 0;          /* volume options */
+    DVC.dosvc_reserved = 0;         /* reserved for future use */
+
     /* initialize the boot block device as a dosFs device named <bootDir> */
 
     if (dosFsDevInit (bootDir, pBootDev, NULL) == NULL)
     {
+        if (dosFsDevInit (bootDir, pBootDev, &DVC) == NULL)
+	 {
             printErr ("dosFsDevInit failed.\n");
             return (ERROR);
+        }
     }
     return (OK);
 }
    

(From: Christian Doppelbauer, Christian.Doppelbauer@br-automation.co.at)

Another possibility is to use the following code:

STATUS initMyFDisk()
{
    IMPORT int dosFsDrvNum;                 /* number Dos file driver */
    fdDrv (FD_INT_VEC, FD_INT_LVL);         /* initialize floppy disk */
    if (dosFsDrvNum == ERROR)
    {
        dosFsInit (NUM_DOSFS_FILES);    /* initialize DOS-FS */
    }
    /*
     * Create the device;
     */
    if (usrFdConfig (0, 0, "/vxA/") == ERROR)
    {
        printErr("initMyFDisk(): usrFdConfig failed.\n");
        return(ERROR);
    }
    return(OK);
}
    

(From: Pritam De, pde@cisco.com)

Q: When I use the RAM-disk as supplied with DosFS2 (configured using the item Hardware->Peripherals->RAM Disk with MSDOS filesystem) it is formatted every time I startup, even if I assign a seperate memory area.

A: Using the device provided as-is this is right. During the initialisation of the device it is formatted. This can be changed by replacing/adding a number of lines to the component INCLUDE_RAM_DISK in the file 10dosfs2.cdf in target\config\comps\vxworks. The definition of INIT_RTN should be changed to:

        INIT_RTN        { void * cbio ; int ramDiskTestFd = -1;\
            cbio=ramDiskDevCreate(RAM_DISK_MEM_ADRS,512,17,RAM_DISK_SIZE/512,0);\
            if(cbio!=NULL){ \
                dosFsDevCreate(RAM_DISK_DEV_name,cbio,RAM_DISK_MAX_FILES,NONE);\
                if(RAM_DISK_FORMAT_ALWAYS == FALSE){ \
                    ramDiskTestFd = open(RAM_DISK_DEV_name, 2, 0);\
                } \
                if((RAM_DISK_FORMAT_ALWAYS != FALSE)||(ramDiskTestFd == -1)){\
                    dosFsVolFormat(cbio,DOS_OPT_BLANK | DOS_OPT_QUIET, NULL);\
                } \
                if(ramDiskTestFd != -1){ \
                    close(ramDiskTestFd);\
                } \
            }}
    

Also a configuration parameter should be added, called RAM_DISK_FORMAT_ALWAYS. To define this parameter the Parameter-definition has to be added:

Parameter RAM_DISK_FORMAT_ALWAYS
        {
        name            Format always, even if already formatted
        TYPE            bool  
        DEFAULT         FALSE
        }
    

When this parameter is set to TRUE the disk is always formatted, just like the original situation. When this parameter is set to FALSE (the default situation) the disk is only formatted when the open of the RAM-disk root does not succeed.

Q: It seems that VxWorks does not write to the file on the host but is buffering all file output in memory until the end of the application or until the file is closed. Also when I open a large file it seems that VxWorks is allocating memory to store the complete file, and the open fails when not enough memory is available.

A: It sounds like you were using netdrv and that's what happened when a file is either being read or written (the whole file is buffered in memory). Try nfs.
(From: M Lang, mlang@fst.jpl.nasa.gov)

Q: What is the maximum number of open file descriptors in VxWorks? Is it configurable?

A: Yes, see config/all/configAll.h:

#define NUM_FILES 50 /* max 50 files open simultaneously */
    

The maximum number is 256, as this is a hard-coded maximum for select, but you can only use up to 253 files, as you cannot use fd's 0, 1 and 2.

Increasing NUM_FILES to 100, only got us to about 79 file descriptors. Then we had to change to following #defines as well

/*Changed SJP 2/1/00 all entries were 64 and then bumbed to 128*/
/*Since the NUM_FILES in configAll.h was changed to 256 we had to increase
the size of the clusters that are used when opening sockets*/
#define NUM_SYS_64    256 /* 64 byte system clusters */
#define NUM_SYS_128   256 /* 128 byte system clusters */
#define NUM_SYS_256   256 /* 256 byte system clusters */
#define NUM_SYS_512   256 /* 512 byte system clusters */
    

(From: Peter Marqui (peter.marqui@rauland.com))

Q: I would like to use more than 256 files in a select. Is this possible?

A: There is a fixed limit of 256 bits in an fd_set so you can only select on fd's in the range [0..255].
Unfortunately changing FD_SETSIZE to a value above 255 won't have any effect unless you also recompile the VxWorks select library (and, for safety, anything else that depends on FD_SETSIZE).
I investigated various ways to solve/work around this problem several years ago, and concluded that the only reasonable way to do so was to get source code for the VxWorks selectLib and either recompile it with a fixed (different) FD_SETSIZE, or (as I eventually did) make it support a variable sized fd_set. Bear in mind that you will need a source licence for selectLib.c before you can make any of these changes.
(From: Ian Willats, ian.willats@telelogic.com)

Q: Is it possible to use files larger than 4 Gbytes?

A: In DosFs 2.0, when using Microsoft compatible FAT32 format, this limitation exists due to MSFT's 32-bit file size field in directory structure.
If you however format DosFs 2.0 disk with the proprietary WindRiver long file names (aka VX_LONG), you will get a 40-bit file size, and 64-bit counterparts of the standard ioctl codes, which use a 64-bit integer arguments as the third ioctl argument.
Also, if my memory serves me well, we have also implemented these same 64-bit API calls on the rawFsLib, in the course of developing DosFs 2.0, so the extended rawFs does exist somwwhere, but I am not sure if and how you can obtain this from WindRiver.
Finally, there is the alternative of circumcenting file systems alltogether, and use the Block Device API to directly interface the disk driver. This is similar to using RAW file system, but you will be forced to sector aligned I/O, i.e. your disk address will be a sector number, and all your R/W buffers will have to be multiple of 512 bytes (preferrably aligned if the driver has got DMA in it).
(From: Leonid Rosenboim)

Q: I cannot mount my ATA CDROM drive

A: This is because CD-ROM drives usually do not implement the ATA protocol, as hard drives do, but instead use the ATAPI protocol, which runs over the same IDE hardware but is something else.
Couple of years back we did an ATAPI driver addition, which makes the VxWorks ATA driver know both ATA and ATAPI protocols, but its burried somewhere at WindRiver. Try to ask your FAE to get you the driver.
(From: Leonid Rosenboim, leonid@bitband.com)

Q: How can I convert from "file pointer" (fp) to "file description" (fd)

A: Use the following: fd = fileno(fp);
(From: Donald McLachlan, don@mars.dgrc.crc.ca)

Q: When closing a file I get the errno 226. The error message I get is:

HELLO.TXT: The system cannot find the file specified.
HELLO.TXT: Access is denied.
    

A: You are probably using the FTP based netDrv file system. That would explain both the error number, and the fact that it only failed when you closed the file.
Firstly, the reason for failing only when you close is that netDrv (whether using ftp or rsh), will only actually write a file on the host file system when you close it. Up until then, the file has been held in memory. You can tell which protocol you are using very easily: if you entered a password in the bootline for the taregt, you'll be using ftp, otherwise you'll be using rsh. Of course, if your host is a Windoze box, you only have the choice of ftp.
Now, the error number. This is a little quirk of the ftp client library in VxWorks. It will place any FTP protocol error in the errno field so that you can see it. So, error 226 is probably an FTP error code. Looking this up at http://hpcf.nersc.gov/help/access/ftp_error_codes.html you'll find the following:
226 Closing data connection. Requested file action successful (for example, file transfer or file abort).
The clue as to what is happening though is in the messages; "Access Denied" suggests that the ftp user you specified in the bootline does not have write permission. Check the config. of the ftp server (for Windoze), or check whether the user has write access to the directory you are using for Unix.
(From:John, john_94501@yahoo.com)

Should I use "/tffs0" or "/tffs0/" when creating a filesystem?

A: Well, since vxWorks doesn't parse filenames (they are treated as strings) until you get into the fs code itself, if you call a filesystem "/tffs0" then names like "/tffs0fred" are passed into the fs code which will treat them as being identical to "/tffs0/fred" this probably isn't quite what you had in mind:-)
So in order to require the "/" between the filesystem name and a file within the system you need to end the filesystem name with a "/". Unfortunately this is counter intuitive and not processed consistently within vxWorks.
The worst culprit is the NFS export code which, when matching the name supplied by the remote system, strips a '/' of the wrong name! So of you export "/fred/" you have to specify "/fred//" in order to mount it (from a unix system). You might think this is a bug, however attepts to raise it failed because the documentation says (somewhere) that NFS exported FS must not end in a '/'.
(From: David Laight, david@spamm.me.l8s.co.uk)

Q: Announcement of the Linux based VXEXT1.0 implementation

A: I just want to announce that I released a reverse engineered Linux based filesystem implementation of the so called "VXEXT1.0" filesystem shipped with VxWorks 5.2+ systems today. And as this might be helpfull for some people in here I want to let you know the URL about it:
http://www.jens-langner.de/vxext_fs/ So if you do want to access your VxWorks harddisks formatted with the VXEXT1.0 dosFS filesystem mode, the above filesystem driver should allow you to access those drives in read-only mode from a linux machine.
Please also note, that this driver was already submitted to the linux kernel mailinglist for a possible integration into the linux kernel tree. However, if it might make its way into the kernel depends on how the linux kernel developers may think it is usefull or not.
No matter what, please feel free to comment on it and also try it if you do have a linux system from which you can access a harddisk that you have formatted/used in a VxWorks 5.2+ system.
But please note, that the implementation just targets harddisks which are formatted/initialized with the "extended DOS" filesystem mode in dosFS enabled.
(From: Jens Langner, J.Langner@fz-rossendorf.de)

Q: How can I switch off output to the shell window?

A: Use ioGlobalStdSet and/or ioTaskStdSet with the filepointer to file /null. This is the /dev/null device in VxWorks, and makes sure that all the output goes somewhere where you don have to look at it.....

© J.A. Borkhuis, 2000 - 2005