Hi Team, If target system is not windows then SharedAccess=0 which imeans there is no need to implement it.
#ifndef WIN32 > file->SharedAccess = 0; > #endif > file->file_handle = CreateFileW(file->fullpath, > file->DesiredAccess, > file->SharedAccess, NULL, > CreateDisposition, > file->FileAttributes, > NULL); Any thoughts on the above ? If that is not the case then what is it that I am missing? Thanks On Thu, Feb 7, 2019 at 11:13 PM Amarjeet Singh <[email protected]> wrote: > Hi Team, > > Findings on the below issue is as follows :- > > I went ahead read about the shared access from *File System Behavior in > the Microsoft Windows Environment* DOCS > in which there is description of OPLOCK SEMANTICS. > > Oplock Semantics >> 2.1 Overview >> >>> Opportunistic locks, or oplocks, provide a mechanism that allows file >>> server clients (such as those utilizing the SMB and SMB2 protocols) to >>> dynamically alter buffering strategy for a given file or stream in a >>> consistent manner to increase performance and to reduce network use. To >>> increase the network performance for remote file operations, a client can >>> locally buffer file data, which reduces or eliminates the need to send and >>> receive network packets. For example, a client may not have to write >>> information into a file on a remote server if the client knows that no >>> other process is accessing the data. Likewise, the client may buffer >>> read-ahead data from the remote file if the client knows that no other >>> process is writing data to the remote file. Applications and drivers can >>> also use oplocks to transparently access files without affecting other >>> applications that might need to use those files. >>> Oplocks are granted on stream handles, meaning that the operations apply >>> to the given open stream of a file and, in general, operations on one >>> stream do not affect oplocks on a different stream. There are exceptions to >>> this, which are explicitly listed below. >>> There are currently eight different types of oplocks: >>> >>>> 1. A Level 2 (or shared) oplock indicates that there are multiple >>>> readers of a stream and no writers. This supports client read caching. >>>> 2. A Level 1 (or exclusive) oplock allows a client to open a stream for >>>> exclusive access and allows the client to perform arbitrary buffering. This >>>> supports client read caching and write caching. >>>> 3. A Batch oplock (also exclusive) allows a client to keep a stream >>>> open on the server even though the local accessor on the client machine has >>>> closed the stream. This supports scenarios where the client needs to >>>> repeatedly open and close the same file, such as during batch script >>>> execution. This supports client read caching, write caching, and handle >>>> caching. >>>> 4. A Filter oplock (also exclusive) allows applications and file system >>>> filters (including minifilters), which open and read stream data, a way to >>>> “back out” when other applications, clients, or both try to access the same >>>> stream. This supports client read caching and write caching. >>>> 5. A Read (R) oplock (shared) indicates that there are multiple readers >>>> of a stream and no writers. This supports client read caching. >>>> 6. A Read-Handle (RH) oplock (shared) indicates that there are multiple >>>> readers of a stream, no writers, and that a client can keep a stream open >>>> on the server even though the local accessor on the client machine has >>>> closed the stream. This supports client read caching and handle caching. >>>> 7. A Read-Write (RW) oplock (exclusive) allows a client to open a >>>> stream for exclusive access and allows the client to perform arbitrary >>>> buffering. This supports client read caching and write caching. >>>> 8. A Read-Write-Handle (RWH) oplock (exclusive) allows a client to keep >>>> a stream open on the server even though the local accessor on the client >>>> machine has closed the stream. This supports client read caching, write >>>> caching, and handle caching. >>>> Level 1, Level 2, and Batch oplocks were implemented in Windows NT 3.1. >>>> The Filter oplock was added in Windows 2000. R, RH, RW, and RWH oplocks >>>> have been added in Windows 7. >>> >>> > Please find the attached document of the above. > > Guacamole VIRTUAL FILE DRIVE REDIRECTION hasn't implented it whereas > FreeRDP 2.0.0 has implemented it. > > *Guacamole Code :* > >> void guac_rdpdr_fs_process_create(guac_rdpdr_device* device, >> wStream* input_stream, int completion_id) { >> wStream* output_stream; >> int file_id; >> int desired_access, file_attributes, sharedAccess; >> int create_disposition, create_options, path_length; >> char path[GUAC_RDP_FS_MAX_PATH]; >> /* Read "create" information */ >> Stream_Read_UINT32(input_stream); /* Desired Access */ >> Stream_Seek_UINT64(input_stream); /* allocation size */ >> Stream_Read_UINT32(input_stream, file_attributes); >> Stream_Read_UINT32(input_stream, sharedAccess); /* shared access */ >> Stream_Read_UINT32(input_stream, create_disposition); >> Stream_Read_UINT32(input_stream, create_options); >> Stream_Read_UINT32(input_stream, path_length); >> } > > *FreeRDP 2.0.0 Code while creating or opening a file:-* > >> >> if (dwShareMode & FILE_SHARE_READ) >> lock.l_type = F_RDLCK; >> if (dwShareMode & FILE_SHARE_WRITE) >> lock.l_type = F_RDLCK; >> #else >> if (dwShareMode & FILE_SHARE_READ) >> lock = LOCK_SH; >> if (dwShareMode & FILE_SHARE_WRITE) >> lock = LOCK_EX; >> #endif >> if (dwShareMode & (FILE_SHARE_READ | FILE_SHARE_WRITE)) >> { >> #ifdef __sun >> if (fcntl(fileno(pFile->fp), F_SETLKW, &lock) == -1) >> #else >> if (flock(fileno(pFile->fp), lock) < 0) >> #endif >> { >> #ifdef __sun >> WLog_ERR(TAG, "F_SETLKW failed with %s [0x%08X]", >> #else >> WLog_ERR(TAG, "flock failed with %s [0x%08X]", >> #endif >> strerror(errno), errno); >> SetLastError(map_posix_err(errno)); >> FileCloseHandle(pFile); >> return INVALID_HANDLE_VALUE; >> } > > > I have tried mstsc and redirected the shared drive and tried to save the > file in it and it works whereas it fails in Guacamole Server Shared Drive [ > For Info : I tried everywhere including download and outside the download > folder as well.] > > > I tried another solution also which provides RDP on browser and it works > fine. > > I will try with *FreeRDP 2.0.0* and *FreeRDP 1.0.2* client on windows as > well and update with you the same. > > Thanks, > Amarjeet Singh > > > > On Wed, Feb 6, 2019 at 1:43 PM Amarjeet Singh <[email protected]> > wrote: > >> If you are attempting to save the file directly into the "Download" >>> folder, >>> it is likely that the application is repeatedly closing and reopening the >>> file over the course of saving things. As Guacamole will automatically >>> delete the file and begin downloading once the file is closed, an >>> application which behaves in this way will not work correctly. You will >>> need to save the file elsewhere and then move it to the "Download" >>> folder. >> >> >> Thanks Mike for helping me out with this. >> >> I have tried to save the file instead of downloading in the Download >> folder and got the same error. >> >> Thanks, >> Amarjeet Singh >> >> >> >> On Wed, Feb 6, 2019 at 12:11 AM Mike Jumper <[email protected]> wrote: >> >>> On Tue, Feb 5, 2019 at 9:50 AM Amarjeet Singh <[email protected]> >>> wrote: >>> >>> > ... >>> > While trying to download pdf and rtf files in the local operating >>> system [ >>> > Windows 10 ], I am getting the below error :- >>> > >>> > Report Builder *REP-0081* error during file i/o operation scaba 16 >>> > >>> > >>> > ... It is only writing *10 bytes* and corrupted pdf file is downloaded. >>> > >>> >>> If you are attempting to save the file directly into the "Download" >>> folder, >>> it is likely that the application is repeatedly closing and reopening the >>> file over the course of saving things. As Guacamole will automatically >>> delete the file and begin downloading once the file is closed, an >>> application which behaves in this way will not work correctly. You will >>> need to save the file elsewhere and then move it to the "Download" >>> folder. >>> >>> - Mike >>> >>
