Problem with Windows 11 using DIRECTORY()

questions
1

Code (works with < W11):

  DIRECTORY(qFiles,CLIP(LONGPATH(PATH())) & '\EDI*.txt',ff_:DIRECTORY)
  Recs = RECORDS(qFiles)

  IF Recs
    GET(qFiles,Recs)
    gsEdiInFileName = CLIP(LONGPATH(PATH())) & '\' & qFiles.name
    START(ImportEdiL)
  END

I get the error:

Access denied C:$recycle.bin (something like this - OS is german)

Any suggestions?

Regards

2

A couple of questions come to mind.

  1. What is the value of PATH()? Have you confirmed it is what you expect?
  2. Does it work if you run the program elevated As Admin?
  3. Which of the file queue types are you using with Directory()? I’ve run into troubles using the older ff_:queue type.
    Using DIRECTORY with ff_:queue crashes with Remote Desktop Service and User Profile Disks
1 Like
3

There is no need to use LONGPATH() inside PATH() it will work as:
DIRECTORY(qFiles, CLIP( LONGPATH() ) & '\EDI*.txt',ff_:DIRECTORY)
gsEdiInFileName = CLIP( LONGPATH() ) & '\' & qFiles.name

Since C6 or C7 there is no need to Clip PATH() or most RTL functions, they no longer return all the trailing spaces.

IIRC there is a “bug” that LongPath() clears the ErrorCode(). This is seen sometimes when a Message() showing an ErrorCode() includes the LongPath() which clears the error … so confusing.

Rick probably caught your problem that your DIRECTORY gFiles must be QUEUE(File:Queue) and not QUEUE(ff_:queue) which only supports short file names.

Tip: I edit LibSrc BuiltIns.clw and comment out the Directory(ff_:queue .... ) prototype so if it is accidentally used there is a compiler error so I know I need to fix it to use File:Queue.

2 Likes
4

This is not a bug because expanding of the path to fully qualified form can run into different kinds of errors, for example, if networked drive is offline. If a function can change the error code, it clears it if no errors occurred.

Clearing of the error code is the very first thing the PATH(), SHORTPATH() and LONGPATH() functions do explicitly at least since C4.

5

LongPath() is Not documented in the help as setting the ErrorCode() the way SetPath() specifies it can set Error 3. So that’s the Bug that it is not documented to set an error. The Windows GetLongPathNameA() on MSDN says it sets GetLastError(), it also Returns a BOOL,

I could see calling LongPath( string ) with a Paramater setting an ErrorCode(), but without a Paramater LongPath() to get the current path should not set or clear error.

IIRC LongPath() does Not return with an ErrorCode() set, it just always clears the RTL Error state.

6

THX. I give it a try

7

LONGPATH() is actually the enemy.