Recent

Author Topic: FSOpenFork, FSCloseFork "DEPRECATED"… what else ?  (Read 4680 times)

Gilles

  • New Member
  • *
  • Posts: 37
FSOpenFork, FSCloseFork "DEPRECATED"… what else ?
« on: June 07, 2018, 08:58:38 am »
How do i hate this recurrent word at Apple : "DEPRECATED" !!! (ouuhh le vilain mot)

Bref

Since these deprecated functions (FSOpenFork, FSCloseFork and so on) don't work correctly since Sytem 10.13 (a -54 error often occurs when files are shared)
probably because of the new APFS

Since the Functions of the unit System from Free Pascal are not enough

What solutions do you think are the best (and sustainable) ?
TurboPascal -> ThinkPascal -> CodeWarrior -> XCode with FPC -> (Well-deserved) Retirement (but not yet, not yet…)

Phil

  • Hero Member
  • *****
  • Posts: 2737
Re: FSOpenFork, FSCloseFork "DEPRECATED"… what else ?
« Reply #1 on: June 07, 2018, 03:02:46 pm »
Since these deprecated functions (FSOpenFork, FSCloseFork and so on) don't work correctly since Sytem 10.13 (a -54 error often occurs when files are shared)
probably because of the new APFS

Actually, those functions were deprecated in 10.8.

Why do you need them? Are you trying to read a resource fork?

Gilles

  • New Member
  • *
  • Posts: 37
Re: FSOpenFork, FSCloseFork "DEPRECATED"… what else ?
« Reply #2 on: June 07, 2018, 07:37:38 pm »
No, data…

for example, for FSOpenFork :

I found :

"FSOpenFork (page 590) Deprecated in OS X v10.8 Opens any fork of a file or directory for streaming access. (Deprecated. At the POSIX/BSD layer, use open(2) OS X Developer Tools Manual Page and flock instead. To open a data fork at the Foundation layer, use NSFileHandle APIs instead.)"

but that doesn't help…

that's how I used it :

Code: Pascal  [Select][+][-]
  1. xErr := FSOpenFork(xx_ref, xx_ULL.ull_hfs_dfn.length, @xx_ULL.ull_hfs_dfn.unicode, x_prm, x_rfn)

It worked well and still work well
but on HFS+
On the new format, there are problems if many users try to access the same file
« Last Edit: June 07, 2018, 07:40:25 pm by Gilles »
TurboPascal -> ThinkPascal -> CodeWarrior -> XCode with FPC -> (Well-deserved) Retirement (but not yet, not yet…)

Gilles

  • New Member
  • *
  • Posts: 37
Re: FSOpenFork, FSCloseFork "DEPRECATED"… what else ?
« Reply #3 on: June 18, 2018, 07:25:46 pm »
Well, the error -54 seemed to have been a bug of the system and is supposed to be solved in macOS X 10.13.5

still deprecated but always supported
TurboPascal -> ThinkPascal -> CodeWarrior -> XCode with FPC -> (Well-deserved) Retirement (but not yet, not yet…)

ASBzone

  • Hero Member
  • *****
  • Posts: 678
  • Automation leads to relaxation...
    • Free Console Utilities for Windows (and a few for Linux) from BrainWaveCC
Re: FSOpenFork, FSCloseFork "DEPRECATED"… what else ?
« Reply #4 on: June 18, 2018, 10:48:09 pm »
but that doesn't help…

What does that mean?  What is the error message?


On the new format, there are problems if many users try to access the same file

Error message?
-ASB: https://www.BrainWaveCC.com/

Lazarus v2.2.7-ada7a90186 / FPC v3.2.3-706-gaadb53e72c
(Windows 64-bit install w/Win32 and Linux/Arm cross-compiles via FpcUpDeluxe on both instances)

My Systems: Windows 10/11 Pro x64 (Current)

Gilles

  • New Member
  • *
  • Posts: 37
Re: FSOpenFork, FSCloseFork "DEPRECATED"… what else ?
« Reply #5 on: June 19, 2018, 07:31:50 am »
when many users wanted to open a file already opened and closed by another user (in a local AFP network), it often generated a -54 error. Not always but often. The only possibility being restarting the server.
Probably because the closed state of the file was badly transmitted.
And that since 10.13 when server disk was formated in APFS.
« Last Edit: June 19, 2018, 07:37:13 am by Gilles »
TurboPascal -> ThinkPascal -> CodeWarrior -> XCode with FPC -> (Well-deserved) Retirement (but not yet, not yet…)

Gilles

  • New Member
  • *
  • Posts: 37
Re: FSOpenFork, FSCloseFork "DEPRECATED"… what else ?
« Reply #6 on: June 26, 2018, 04:50:49 pm »
well I maybe found the truc :

ioRefNum used to be declared as SInt16 and used to be positive
ioRefNum is now declared as FSIORefNum which is SInt16 if not CPU_64 and SInt32 if CPU_64
thus : if SInt16 (not CPU_64) is the declaration, it may be negative
isn't that nice ?
TurboPascal -> ThinkPascal -> CodeWarrior -> XCode with FPC -> (Well-deserved) Retirement (but not yet, not yet…)

 

TinyPortal © 2005-2018