Re: [Samba] NFS quotas: truncated files without warning
Opened bug in RHs bugzilla ( https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=244848 ) En/na simo ha escrit: On Mon, 2007-06-18 at 12:21 -0700, Jeremy Allison wrote: On Mon, Jun 18, 2007 at 08:48:09PM +0200, SER.RI-TIC - David Losada wrote: Hi Jeremy, actually, I have adapted your patch for applying to the current RHEL4 Samba release (samba-3.0.10-1.4E.12.2). Would you mind to check if I have made any flagrant mistakes? If anyone reads this and decides to try it, please bear in mind it's experimental. Summary of what I have modified from your patch: * no patch for smbd/aio.c , because it's just not there yet in this release * in smbd/fileio.c:sync_file() , doesn't check for the sync always directive, the check's not originally there * in smbd/fileio.c:sync_file() , for accessing the fd, it's just fsp-fd, not fsp-fh-fd * in smbd/reply.c:reply_write() , ignored the hunk around CHECK_WRITE(fsp), because in this release that check is not made * took into account that the checking of conditions for forcing synchronization (lp_strict_sync, lp_sync_always, write_through) hadn't yet been refactored into the fileio.c:sync_file() function If patching from a vanilla samba-3.0.10 release, should apply the smbd_deferred_open_backport patch first. I'm also attaching it for convenience. If your patch makes it to next Samba official release, and this patch receives your blessing, could we put them in consideration of RedHat for an errata? The fact it helps to avoid silent data corruption in an scenario like ours, should be interesting for them. This work looks good - it's not a complex change. The fix will definately be in 3.0.25b, I'll let Simo pick up the change for RH for their older versions if he thinks it's warrented. I'd really prefer an entry in RHs bugzilla to be able to easily pick it up :-) Simo. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
Re: [Samba] NFS quotas: truncated files without warning
On Tue, 2007-06-19 at 16:15 +0200, SER.RI-TIC - David Losada wrote: Opened bug in RHs bugzilla ( https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=244848 ) Thank you! Simo. -- Simo Sorce Samba Team GPL Compliance Officer email: [EMAIL PROTECTED] http://samba.org -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
Re: [Samba] NFS quotas: truncated files without warning
Hi Jeremy, just tried your patch on 3.0.25a (it applied cleanly) and configured the suggested directives (strict allocate, strict sync, sync always). This way, the clients I have tested (Win2K with clear-text authentication, smbclient) get notified immediately about the lack of available quota. Relevant log excerpts: (smbclient) [2007/06/11 22:24:12, 5] smbd/reply.c:reply_write_and_X(3159) reply_write_and_X: sync_file for samba-3.0.10-1.4E.12.2.src.rpm returned NT_ST ATUS_DISK_FULL [2007/06/11 22:24:12, 3] smbd/error.c:error_packet_set(106) error packet at smbd/reply.c(3160) cmd=47 (SMBwriteX) NT_STATUS_DISK_FULL (Win2K) [2007/06/11 22:25:16, 5] smbd/reply.c:reply_write_and_X(3159) reply_write_and_X: sync_file for rvtls_putty.reg returned NT_STATUS_DISK_FULL [2007/06/11 22:25:16, 3] smbd/error.c:error_packet_set(106) error packet at smbd/reply.c(3160) cmd=47 (SMBwriteX) NT_STATUS_DISK_FULL What do you think are the chances of backporting it to 3.0.10 and 3.0.23c? I am willing to do the effort, just would like to know your opinion on it, since you seem to know the affected code very well ;) It would be nice very nice for us if we could send it to RedHat so they consider to issue an errata to RHEL4 and 5. About limiting the syncy behaviour just to the space allocation operation... I think maybe we are not interested in persuing it by now and we could sacrifice performance for safety. thank you, En/na Jeremy Allison ha escrit: On Fri, Jun 15, 2007 at 08:23:49PM +0200, SER.RI-TIC - David Losada wrote: mmm... well, it doesn't seem to be working like that in the version that ships with RHEL4. I will get around to try it on a fresh build on monday and report to you about it. Apply this patch and let me know if it fixes it (will be in 3.0.25b). Jeremy. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
Re: [Samba] NFS quotas: truncated files without warning
On Mon, Jun 18, 2007 at 06:53:11PM +0200, SER.RI-TIC - David Losada wrote: Hi Jeremy, just tried your patch on 3.0.25a (it applied cleanly) and configured the suggested directives (strict allocate, strict sync, sync always). This way, the clients I have tested (Win2K with clear-text authentication, smbclient) get notified immediately about the lack of available quota. Relevant log excerpts: (smbclient) [2007/06/11 22:24:12, 5] smbd/reply.c:reply_write_and_X(3159) reply_write_and_X: sync_file for samba-3.0.10-1.4E.12.2.src.rpm returned NT_ST ATUS_DISK_FULL [2007/06/11 22:24:12, 3] smbd/error.c:error_packet_set(106) error packet at smbd/reply.c(3160) cmd=47 (SMBwriteX) NT_STATUS_DISK_FULL (Win2K) [2007/06/11 22:25:16, 5] smbd/reply.c:reply_write_and_X(3159) reply_write_and_X: sync_file for rvtls_putty.reg returned NT_STATUS_DISK_FULL [2007/06/11 22:25:16, 3] smbd/error.c:error_packet_set(106) error packet at smbd/reply.c(3160) cmd=47 (SMBwriteX) NT_STATUS_DISK_FULL What do you think are the chances of backporting it to 3.0.10 and 3.0.23c? I am willing to do the effort, just would like to know your opinion on it, since you seem to know the affected code very well ;) It would be nice very nice for us if we could send it to RedHat so they consider to issue an errata to RHEL4 and 5. It should be reasonably easy to do - that code really hasn't changed much in a long time. I'm willing to answer any questions you might have on it. Simo is the RedHat Samba maintainer, so he might be able to help get this into the RH distro. Jeremy. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
Re: [Samba] NFS quotas: truncated files without warning
Hi Jeremy, actually, I have adapted your patch for applying to the current RHEL4 Samba release (samba-3.0.10-1.4E.12.2). Would you mind to check if I have made any flagrant mistakes? If anyone reads this and decides to try it, please bear in mind it's experimental. Summary of what I have modified from your patch: * no patch for smbd/aio.c , because it's just not there yet in this release * in smbd/fileio.c:sync_file() , doesn't check for the sync always directive, the check's not originally there * in smbd/fileio.c:sync_file() , for accessing the fd, it's just fsp-fd, not fsp-fh-fd * in smbd/reply.c:reply_write() , ignored the hunk around CHECK_WRITE(fsp), because in this release that check is not made * took into account that the checking of conditions for forcing synchronization (lp_strict_sync, lp_sync_always, write_through) hadn't yet been refactored into the fileio.c:sync_file() function If patching from a vanilla samba-3.0.10 release, should apply the smbd_deferred_open_backport patch first. I'm also attaching it for convenience. If your patch makes it to next Samba official release, and this patch receives your blessing, could we put them in consideration of RedHat for an errata? The fact it helps to avoid silent data corruption in an scenario like ours, should be interesting for them. kind regards, En/na Jeremy Allison ha escrit: On Fri, Jun 15, 2007 at 08:23:49PM +0200, SER.RI-TIC - David Losada wrote: mmm... well, it doesn't seem to be working like that in the version that ships with RHEL4. I will get around to try it on a fresh build on monday and report to you about it. Apply this patch and let me know if it fixes it (will be in 3.0.25b). Jeremy. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
Re: [Samba] NFS quotas: truncated files without warning
On Mon, Jun 18, 2007 at 08:48:09PM +0200, SER.RI-TIC - David Losada wrote: Hi Jeremy, actually, I have adapted your patch for applying to the current RHEL4 Samba release (samba-3.0.10-1.4E.12.2). Would you mind to check if I have made any flagrant mistakes? If anyone reads this and decides to try it, please bear in mind it's experimental. Summary of what I have modified from your patch: * no patch for smbd/aio.c , because it's just not there yet in this release * in smbd/fileio.c:sync_file() , doesn't check for the sync always directive, the check's not originally there * in smbd/fileio.c:sync_file() , for accessing the fd, it's just fsp-fd, not fsp-fh-fd * in smbd/reply.c:reply_write() , ignored the hunk around CHECK_WRITE(fsp), because in this release that check is not made * took into account that the checking of conditions for forcing synchronization (lp_strict_sync, lp_sync_always, write_through) hadn't yet been refactored into the fileio.c:sync_file() function If patching from a vanilla samba-3.0.10 release, should apply the smbd_deferred_open_backport patch first. I'm also attaching it for convenience. If your patch makes it to next Samba official release, and this patch receives your blessing, could we put them in consideration of RedHat for an errata? The fact it helps to avoid silent data corruption in an scenario like ours, should be interesting for them. This work looks good - it's not a complex change. The fix will definately be in 3.0.25b, I'll let Simo pick up the change for RH for their older versions if he thinks it's warrented. Thanks, Jeremy. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
Re: [Samba] NFS quotas: truncated files without warning
On Mon, 2007-06-18 at 12:21 -0700, Jeremy Allison wrote: On Mon, Jun 18, 2007 at 08:48:09PM +0200, SER.RI-TIC - David Losada wrote: Hi Jeremy, actually, I have adapted your patch for applying to the current RHEL4 Samba release (samba-3.0.10-1.4E.12.2). Would you mind to check if I have made any flagrant mistakes? If anyone reads this and decides to try it, please bear in mind it's experimental. Summary of what I have modified from your patch: * no patch for smbd/aio.c , because it's just not there yet in this release * in smbd/fileio.c:sync_file() , doesn't check for the sync always directive, the check's not originally there * in smbd/fileio.c:sync_file() , for accessing the fd, it's just fsp-fd, not fsp-fh-fd * in smbd/reply.c:reply_write() , ignored the hunk around CHECK_WRITE(fsp), because in this release that check is not made * took into account that the checking of conditions for forcing synchronization (lp_strict_sync, lp_sync_always, write_through) hadn't yet been refactored into the fileio.c:sync_file() function If patching from a vanilla samba-3.0.10 release, should apply the smbd_deferred_open_backport patch first. I'm also attaching it for convenience. If your patch makes it to next Samba official release, and this patch receives your blessing, could we put them in consideration of RedHat for an errata? The fact it helps to avoid silent data corruption in an scenario like ours, should be interesting for them. This work looks good - it's not a complex change. The fix will definately be in 3.0.25b, I'll let Simo pick up the change for RH for their older versions if he thinks it's warrented. I'd really prefer an entry in RHs bugzilla to be able to easily pick it up :-) Simo. -- Simo Sorce Samba Team GPL Compliance Officer email: [EMAIL PROTECTED] http://samba.org -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
[Samba] NFS quotas: truncated files without warning
Hi, we have some Samba instances serving files from a bunch of NFS exports provided by a NAS appliance. Coming from Solaris, we recently have been testing to run our Samba servers on Linux (RHEL 4, Samba 3.0.10-1.4E.12.2). One caveat we didn't expect is that, on Linux, NFS quota errors are reported on calls to close() or fsync(), but not on calls to write(). Through smbclient, we have checked that Samba correctly reports the error to the client (NT_STATUS_DISK_FULL closing remote file ...). However, Windows 2000 clients silently ignore this error when closing the file, leaving the file truncated with no warning to the user (something we really don't want to happen!) We have tried strict sync = yes and sync always = yes configuration directives, to no avail. Have also googled trying to find an answer, but couldn't find one. I don't think we are the only ones with this kind of setup.. anyone has an idea of how to handle this scenario correctly? kind regards, -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
Re: [Samba] NFS quotas: truncated files without warning
On Fri, Jun 15, 2007 at 06:44:47PM +0200, David Losada wrote: Hi, we have some Samba instances serving files from a bunch of NFS exports provided by a NAS appliance. Coming from Solaris, we recently have been testing to run our Samba servers on Linux (RHEL 4, Samba 3.0.10-1.4E.12.2). One caveat we didn't expect is that, on Linux, NFS quota errors are reported on calls to close() or fsync(), but not on calls to write(). Through smbclient, we have checked that Samba correctly reports the error to the client (NT_STATUS_DISK_FULL closing remote file ...). However, Windows 2000 clients silently ignore this error when closing the file, leaving the file truncated with no warning to the user (something we really don't want to happen!) We have tried strict sync = yes and sync always = yes configuration directives, to no avail. Have also googled trying to find an answer, but couldn't find one. I don't think we are the only ones with this kind of setup.. anyone has an idea of how to handle this scenario correctly? Try strict allocate = yes to which will cause Samba to actually allocate space on a Windows client set allocation size call - this should fail if over quota and be at the right place for the Windows clients to see it. Jeremy. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
Re: [Samba] NFS quotas: truncated files without warning
Hi Jeremy, thank you for the tip. Unfortunately, this hasn't proved succesful.. how I tested it: from W2K, as an user with a completely full quota, I drop a 11788 byte file into the share. It produces the following system calls in the server: write(25, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 4096) = 4096 write(25, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 4096) = 4096 write(25, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 3596) = 3596 (4096+4096+3596 = 11788) so my Samba is verifying the availability of storage space through the write() system call, which doesn't generate NFS quota errors, ugh. The thing is that an fsync() after these write() calls would probably get me the NFS quota error... maybe it's implemented this way in a newer Samba release? kind regards, En/na Jeremy Allison ha escrit: On Fri, Jun 15, 2007 at 06:44:47PM +0200, David Losada wrote: Hi, we have some Samba instances serving files from a bunch of NFS exports provided by a NAS appliance. Coming from Solaris, we recently have been testing to run our Samba servers on Linux (RHEL 4, Samba 3.0.10-1.4E.12.2). One caveat we didn't expect is that, on Linux, NFS quota errors are reported on calls to close() or fsync(), but not on calls to write(). Through smbclient, we have checked that Samba correctly reports the error to the client (NT_STATUS_DISK_FULL closing remote file ...). However, Windows 2000 clients silently ignore this error when closing the file, leaving the file truncated with no warning to the user (something we really don't want to happen!) We have tried strict sync = yes and sync always = yes configuration directives, to no avail. Have also googled trying to find an answer, but couldn't find one. I don't think we are the only ones with this kind of setup.. anyone has an idea of how to handle this scenario correctly? Try strict allocate = yes to which will cause Samba to actually allocate space on a Windows client set allocation size call - this should fail if over quota and be at the right place for the Windows clients to see it. Jeremy. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
Re: [Samba] NFS quotas: truncated files without warning
On Fri, Jun 15, 2007 at 07:44:22PM +0200, SER.RI-TIC - David Losada wrote: Hi Jeremy, thank you for the tip. Unfortunately, this hasn't proved succesful.. how I tested it: from W2K, as an user with a completely full quota, I drop a 11788 byte file into the share. It produces the following system calls in the server: write(25, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 4096) = 4096 write(25, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 4096) = 4096 write(25, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 3596) = 3596 (4096+4096+3596 = 11788) so my Samba is verifying the availability of storage space through the write() system call, which doesn't generate NFS quota errors, ugh. The thing is that an fsync() after these write() calls would probably get me the NFS quota error... maybe it's implemented this way in a newer Samba release? Yes, that's what we do (I wrote the code :-). I'll add code to force an fsync after these writes if strict sync is also set. I'll post the patch for 3.0.25 once I've done it. Can you not run Samba on the NFS server - that would be the best way to fix this (and avoid double-copies over the network). Jeremy. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
Re: [Samba] NFS quotas: truncated files without warning
On Fri, Jun 15, 2007 at 10:48:58AM -0700, Jeremy Allison wrote: On Fri, Jun 15, 2007 at 07:44:22PM +0200, SER.RI-TIC - David Losada wrote: Hi Jeremy, thank you for the tip. Unfortunately, this hasn't proved succesful.. how I tested it: from W2K, as an user with a completely full quota, I drop a 11788 byte file into the share. It produces the following system calls in the server: write(25, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 4096) = 4096 write(25, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 4096) = 4096 write(25, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 3596) = 3596 (4096+4096+3596 = 11788) so my Samba is verifying the availability of storage space through the write() system call, which doesn't generate NFS quota errors, ugh. The thing is that an fsync() after these write() calls would probably get me the NFS quota error... maybe it's implemented this way in a newer Samba release? Yes, that's what we do (I wrote the code :-). I'll add code to force an fsync after these writes if strict sync is also set. I'll post the patch for 3.0.25 once I've done it. Actually, I've checked the code and this should already be being done. The secret is to set : strict allocate = yes strict sync = yes sync always = yes So force the flush - normally we only do the fsync if the client asks for it on the write call. Jeremy. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
Re: [Samba] NFS quotas: truncated files without warning
mmm... well, it doesn't seem to be working like that in the version that ships with RHEL4. I will get around to try it on a fresh build on monday and report to you about it. However, I can imagine it would result in quite a big performance hit all around. If the 'syncy' behaviour could be restricted to the set allocation size call, maybe that would be a little bit less painful ;) Pity about linux NFS client semantics, it was working nice in Solaris. Maybe should nag the kernel mantainer for this code ;) Right, looking at performance, we should be serving SMB from the NAS appliances. Will need to look again at the possibilities these appliances offer. kind regards and thanks again, En/na Jeremy Allison ha escrit: On Fri, Jun 15, 2007 at 10:48:58AM -0700, Jeremy Allison wrote: On Fri, Jun 15, 2007 at 07:44:22PM +0200, SER.RI-TIC - David Losada wrote: Hi Jeremy, thank you for the tip. Unfortunately, this hasn't proved succesful.. how I tested it: from W2K, as an user with a completely full quota, I drop a 11788 byte file into the share. It produces the following system calls in the server: write(25, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 4096) = 4096 write(25, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 4096) = 4096 write(25, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 3596) = 3596 (4096+4096+3596 = 11788) so my Samba is verifying the availability of storage space through the write() system call, which doesn't generate NFS quota errors, ugh. The thing is that an fsync() after these write() calls would probably get me the NFS quota error... maybe it's implemented this way in a newer Samba release? Yes, that's what we do (I wrote the code :-). I'll add code to force an fsync after these writes if strict sync is also set. I'll post the patch for 3.0.25 once I've done it. Actually, I've checked the code and this should already be being done. The secret is to set : strict allocate = yes strict sync = yes sync always = yes So force the flush - normally we only do the fsync if the client asks for it on the write call. Jeremy. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
Re: [Samba] NFS quotas: truncated files without warning
On Fri, Jun 15, 2007 at 08:23:49PM +0200, SER.RI-TIC - David Losada wrote: mmm... well, it doesn't seem to be working like that in the version that ships with RHEL4. I will get around to try it on a fresh build on monday and report to you about it. However, I can imagine it would result in quite a big performance hit all around. If the 'syncy' behaviour could be restricted to the set allocation size call, maybe that would be a little bit less painful ;) Pity about linux NFS client semantics, it was working nice in Solaris. Maybe should nag the kernel mantainer for this code ;) Right, looking at performance, we should be serving SMB from the NAS appliances. Will need to look again at the possibilities these appliances offer. More data on the exact call being made (debug level 10) would help. Any write call should go through sync_file() before returning success ah - we're not checking the error return from this ! Doh ! Ok, I'll fix that. Jeremy. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
Re: [Samba] NFS quotas: truncated files without warning
On Fri, Jun 15, 2007 at 08:23:49PM +0200, SER.RI-TIC - David Losada wrote:
mmm... well, it doesn't seem to be working like that in the version that
ships with RHEL4. I will get around to try it on a fresh build on monday
and report to you about it.
Apply this patch and let me know if it fixes it (will be in 3.0.25b).
Jeremy.
Index: smbd/reply.c
===
--- smbd/reply.c(revision 23507)
+++ smbd/reply.c(working copy)
@@ -2743,6 +2743,7 @@
BOOL write_through;
files_struct *fsp = file_fsp(inbuf,smb_vwv0);
int outsize = 0;
+ NTSTATUS status;
START_PROFILE(SMBwritebraw);
if (srv_is_signing_active()) {
@@ -2847,7 +2848,13 @@
SSVAL(outbuf,smb_vwv0,total_written);
- sync_file(conn, fsp, write_through);
+ status = sync_file(conn, fsp, write_through);
+ if (!NT_STATUS_IS_OK(status)) {
+ DEBUG(5,(reply_writebraw: sync_file for %s returned %s\n,
+ fsp-fsp_name, nt_errstr(status) ));
+ END_PROFILE(SMBwritebraw);
+ return ERROR_NT(status);
+ }
DEBUG(3,(writebraw2 fnum=%d start=%.0f num=%d wrote=%d\n,
fsp-fnum, (double)startpos,
(int)numtowrite,(int)total_written));
@@ -2912,7 +2919,13 @@
nwritten = write_file(fsp,data,startpos,numtowrite);
}
- sync_file(conn, fsp, False /* write through */);
+ status = sync_file(conn, fsp, False /* write through */);
+ if (!NT_STATUS_IS_OK(status)) {
+ END_PROFILE(SMBwriteunlock);
+ DEBUG(5,(reply_writeunlock: sync_file for %s returned %s\n,
+ fsp-fsp_name, nt_errstr(status) ));
+ return ERROR_NT(status);
+ }
if(((nwritten == 0) (numtowrite != 0))||(nwritten 0)) {
END_PROFILE(SMBwriteunlock);
@@ -2958,6 +2971,7 @@
char *data;
files_struct *fsp = file_fsp(inbuf,smb_vwv0);
int outsize = 0;
+ NTSTATUS status;
START_PROFILE(SMBwrite);
/* If it's an IPC, pass off the pipe handler. */
@@ -2968,6 +2982,7 @@
CHECK_FSP(fsp,conn);
if (!CHECK_WRITE(fsp)) {
+ END_PROFILE(SMBwrite);
return(ERROR_DOS(ERRDOS,ERRbadaccess));
}
@@ -3003,7 +3018,13 @@
} else
nwritten = write_file(fsp,data,startpos,numtowrite);
- sync_file(conn, fsp, False);
+ status = sync_file(conn, fsp, False);
+ if (!NT_STATUS_IS_OK(status)) {
+ END_PROFILE(SMBwrite);
+ DEBUG(5,(reply_write: sync_file for %s returned %s\n,
+ fsp-fsp_name, nt_errstr(status) ));
+ return ERROR_NT(status);
+ }
if(((nwritten == 0) (numtowrite != 0))||(nwritten 0)) {
END_PROFILE(SMBwrite);
@@ -3040,6 +3061,7 @@
unsigned int smblen = smb_len(inbuf);
char *data;
BOOL large_writeX = ((CVAL(inbuf,smb_wct) == 14) (smblen 0x));
+ NTSTATUS status;
START_PROFILE(SMBwriteX);
/* If it's an IPC, pass off the pipe handler. */
@@ -3130,7 +3152,13 @@
DEBUG(3,(writeX fnum=%d num=%d wrote=%d\n,
fsp-fnum, (int)numtowrite, (int)nwritten));
- sync_file(conn, fsp, write_through);
+ status = sync_file(conn, fsp, write_through);
+ if (!NT_STATUS_IS_OK(status)) {
+ END_PROFILE(SMBwriteX);
+ DEBUG(5,(reply_write_and_X: sync_file for %s returned %s\n,
+ fsp-fsp_name, nt_errstr(status) ));
+ return ERROR_NT(status);
+ }
END_PROFILE(SMBwriteX);
return chain_reply(inbuf,outbuf,length,bufsize);
@@ -3227,7 +3255,13 @@
if (!fsp) {
file_sync_all(conn);
} else {
- sync_file(conn,fsp, True);
+ NTSTATUS status = sync_file(conn, fsp, True);
+ if (!NT_STATUS_IS_OK(status)) {
+ END_PROFILE(SMBflush);
+ DEBUG(5,(reply_flush: sync_file for %s returned %s\n,
+ fsp-fsp_name, nt_errstr(status) ));
+ return ERROR_NT(status);
+ }
}
DEBUG(3,(flush\n));
@@ -5831,6 +5865,7 @@
int smb_doff;
char *data;
files_struct *fsp = file_fsp(inbuf,smb_vwv0);
+ NTSTATUS status;
START_PROFILE(SMBwriteBmpx);
CHECK_FSP(fsp,conn);
@@ -5860,7 +5895,13 @@
nwritten = write_file(fsp,data,startpos,numtowrite);
- sync_file(conn, fsp, write_through);
+ status = sync_file(conn, fsp, write_through);
+ if (!NT_STATUS_IS_OK(status)) {
+ END_PROFILE(SMBwriteBmpx);
+ DEBUG(5,(reply_writebmpx: sync_file for %s returned %s\n,
+ fsp-fsp_name, nt_errstr(status) ));
+
